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Prufungsantrag gem. § 44 PatG ist gestelit 

(S) Verfahren zur kontextspezifischen Remote-Authentifizierung des Datenzugriffs 
@) Ore bislang bekannt kryptografischen Verfahren erlau- 
ben mittels nur einer Chipkarte, die entweder vom Arzt 
Oder vom Patienten gefiihrt wird, entweder den Zu griff 
auf den gesamten Datenbestand des einzelnen Patienten 
Oder auf Daten beliebig anderer Patienten. 
Das neue Verfahren soli dem Arzt nurdann den Zugriff auf 
verschlusselte personenbezogene gesundheitsrelevante 
und auch nur aus der Fachgruppe des fur den Arzt rele- 
vanten Daten ermoglichen, wenn der Patient tatsachlich 
in der Praxis anwensend ist und durch Freigabe seiner 
Chipkarte sein Einverstandnis erklart. 
Sowohi Arzt als auch Patient verfugen uber eine krypto- 
graftsche Chipkarte, die aufgrund der verfahrenseigenen 
Verschlussetung der Obertragungswege bei Etnfuhren 
beider Karten in ein Lesegerat an einem Rechner in der 
I Arztpraxis die Authentiftzierung eines Datenzugriffs 
durch mehrere Personen gewahrleistet. 
Das Verfahren eignet sich fur den mediztnischen und je- 
den Bereich, in dem datenschutzrelevante Daten zum Ein- 
satz kommen. 
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Beschreibung 
2.1 Technisches Gcbiet 

5 [0001] ZugriffskontroUe auf elektronisch gespeicherte, vertrauliche und schutzbediiftige Daten in vert^lter und heie- 
rogener Umgebung, insbesondere auch im Internet 

2.2 Stand der Technik 

11) [0002] Die dargestellte Erfindung baut im wesentlichen auf der Technologie des Internets sowie kryptographischer 
Verfahren auf, also solcher, die digitale Verschlusselung und Signatur verwenden. 

[0003] Soweit moglich, wird zum Stand der Technik auf die im Internet anerkannten RFC ("Request for Comments") 
Bezug genommen, die z. B. unter http:/ / www.rfc-editor.org abrufbar sind. Diese RFC erfiillen einerseits die Funktion 
anerkannter Standards, andererseits dienen sie auch zur fachlichen Diskussion, so daB neue Entwicklungen hier friihzei- 
15 tig ihren Niederschlag finden 

2.2.1 Internet-Protokolie 
2.2.1.1 TCP/IP 

20 

[0004] Das Ruckgrat des Internets bildet eine s tandardisierte ( Jruppe von Netzwerk-I JbertragungsprotokoUen, die hau- 
fig unter dem Kurzel "TCP/IP" zusammengefafit werden aber im weiteren Sinne auch beinhalten: 

- Das "Internet-Protocol" (IP, [RFC 791]) weist jedem Rechner im Internet cine eindeutige Adresse aus 4 Bytes zu 
25 (typische Notation 123.234.56.78) Mehrere Rechner konnen zu Subnetzen zusammengefaBt weiden. 

Der DalenU-ansfer erfolgt in Paketen (typ. ca 1 kByte gro6) Schnitlstellenrechner ("Router") ubemehmen als Ver- 
mitdungsstcllcn die Vcrbindung zwischcn Subnetzen. MuB cin Pakct iibcr mchrcrc Subnctzc hinwcg transporticrt 
werden, wird es von Router zu Router weitergereicht. Im Normalfall ist davon auszugehen, daB weder Sender noch 
Empfanger die Kontrolle uber alle Router und Subnetze der Ubertragungsstrecke besitzen. Deswegen gilt das Inter- 
30 net als inharent unsicher und anfallig fur Abhoren und Verfalschen von Daten sowie falsche Identitatsbehauptungen 

CrP-Spoofing") 

Eine neue Version des Intemet-ProtokoUs (IP- V6, siehe [RFC 1 883]) ist in Vorbereitung, hat sich aber noch nicht in 
der Praxis etabliert. 

- Das "Transmission Control Protocol" CTCP, [RFC 793]) setzt auf IP auf und verdeckt die Paketiibertragung vor 
35 den Anwenderprogrammen. Eine Anwendung fordert von TCP eine Verbindung zu einetn bestimmten Rechner 

(identifiziert uber die IP- Adresse) an. TCP stellt der Applikationen "Sockets" zur Verfugung, ein Schnittstellenpaar, 

uber die sequentiell Daten gelesen und geschrieben werden konnen. Diese Sockets korrespondieren mit denen an 

der Gegenstelle, so daB die Anwendungen auf beiden Rechnem uber dieses Socket-Paar kommunizieren kdnnen, 

ohne sich um die darunterliegende Netzwerkstruktur zu kunmiem. 
40 Um an einem Rechner verschiedene Programme (oder mehrere Instanzen des selben Programmes) unabhangig von- 

einander Verbindungen aufbauen zu lassen, beinhaltet TCP eine "Port- Adresse", die einen bestimmten Socket von 

ggf. mehreren auf einem Rechner identifizieren kann. 

Das "User Datagramm Protocol" (UDP, [RFC 768]) ist eine etwas einfachere Alternative zu TCP und setzt eben- 

falls auf IP auf. UDP kennt keine Vearbindungen wie TCP, sondem sendet beliebig lange Datensequenzen ("Datag- 
45 ramme") an die GegensteUe, ohne auf eine Bestatigung zu warten. UDP verdeckt damit vor allem die Vfermittlungs- 

schicht und die Paketstruktur. 

Auch UDP kennt, wie TCP, mehrere Ports auf einem Rechner. 

- Das Domain-Name-System (DNS, siehe [RFC 1034)/[RFC 1035]) ermogUcht die Zuordnung von Netzwcrk- 
adressen zu leicht einpragsamen Namen (typische Notation: hosLorganisation.land) und die Uberlagerung einor cr- 

50 ganisatorisch ausgerichteten Gliederung des Netzes uber die technische Struktur der IP-Adressen mit den Sub-Net- 

zen. 

Das DNS-System ist als verteilte Datenbank mit vielen Zwischenspeichem ausgelegt. Damit wird es (bei korrekter 
Konfiguration) sehr stabil, jedoch anfallig fiir MiBbrauch durch bewuBte Fehlkonfiguration ("DNS-Spoofing") in 
begrenzten Netzsegmenten. 

55 

2.2.1.2 Universal Ressouice Locators 

[0005] Universal Ressource Locators (URL [RFC 1738]) ordnen jederNetzwerkressource (z.B. Rechner, Mail-Konto, 
60 Textdatei, Bilddalei, Tondatei) einen String zu, iiber den die Re.«vSource im Internet erreicht werden kann. URL enthalten 
typischerweise das verwendete Applikationsprotokoll, den anzusprechenden Server und ggf. weitere Informationen zur 
Spezifikation der Ressource relativ zum Server. 

[0006] Das Konzept der URL wurde im aktuell giiltigen Standard zum "Universal Ressource Identifier" (URI, [RFC 
2396]) erweitert, das fiber die Netzerreichbarkeit hinaus Ressourcen eindeutig identifiziert. 
65 [0007] Eine \JKL kann auch ein Programm oder Program-SchnittsteUe identifizieren. In diesem Fall kann sie eine 
"query" enthalten, also dneEinheit von Daten, die vom identifizierten Programm interpreticrt wird. 
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2.2.1.3 hup 

[0008] HTTP ("Hypertext Transport Protocol") selzt als AnwendungsprolokoU auf TCP auf. Akiuell im Einsatz sind 
die Versionen http 1.0 ([RFC 1945]) und hitp 1.1 ([RFC 2616]). 

. [0009] HTTP vejrbindet einen Client (typiscberweise einen WWW-Biowser) mit einem Server (einen Web-Server). 
Der Client sendel eine Anfrage an den Server, mit der er um die tJbennittlung von Daten bittet. Sowohl der angespro- 
chene Server als auch die IdentifikaUon der Daten auf dem Server erfolgt uber eine URL. 

[0010] http erfolgt in isolierten "Request-Response"-Zyklen, zwischen denen keine Verbindung zwischen Client und 
Server aulrecht erhaken wird. Folgende Request- Arten sind gebrauchlich: 



2.2.1 .4 HTML, XML und Hyperlinks 



10 



- GET: Der Client biltet um die Ubermittlung einer Datei. 
Falls die adressierte Ressource keine Datei, sondem ein Progranun ist, kann eiganzend noch eine "query", also eine 
Datensequenz, mitgereicht werden. In diesem Fall erstelU. das aufgerufene Proramm eine Anl.wortdat.ei, die im Re- 
sponse zuriickgereicht wird. 

- POST: Der Client ubermittelt an den Server eine Liste von Variablen mit Werten. POST-Requests sprechen fast 15 
immer Programme auf der Gegenseite an. POST-Requests resultieren typiscberweise aus ausgefiillten HTML-For- 
mularen. 

[0011] Weitere Request- Arten (PUT, DELETE. . .) sind dagegen wenig gebrauchUch. 

[0012] Das HTTP-Protokoll ermoglicht eine Authentifizierung.des Benutzers (d. h. des Browsers gegenul>er dem Ser- 20 
ver) mit Benutzemamen und Passwort. 

[0013] Um http mit Status-Informalionen zu erweitem, d. h. dafur zu sorgen, daB ein Server sich an Details eines vor- 
hergehenden Requests des gleichen Clients "erinnem" kann, gibt es zwei gangige Mechanismen. Damit kann das an sich 
statuslose Protokoll das Konzept einer "Session", also einer Reihe von Request-Response-Zyklen mit inhaltlichem Zu- 
sammenhang, implementieren: 25 

- Allc Scitcn mit Hyperlinks inncrhalb cincr Session wcrdcn dynamisch gcncricrt. 

Die Session- Variablen werden dabei an die Query aller intemen Hyperlink-URLs angehangt (fur GET-Requests) 
bzw. als POST- Variablen, z. B. in versteckten Fonnularfeldem, hinterlegt. Beim Aktivieren der Links werden diese 
Daten dann vom Browser wieder mit an den Server zuruckgesandt. 30 

- Eine Erweiterung des Standards ([RFC 2965]-"Cookies") ermoglicht es dem Server, im Response ein Variablen- 
Wert-Paar an den Browser zu senden, das dieser lokal speichert und dann bei jedem Request an den selben Server 
mit iibermitteU. 



35 



[0014] Die "Hypertext Markup Language" HTML wurde zunachst bis zur Version HTML 2.0 ([RFC 1866]) im Rah- 
men der Intemetstandards definiert. Inzwischen (mit [RFC 2854]) wurde die Definition an das w3-Konsortium iibertra- 
gen und weiterentwickelt ([HTML401 ], [XHTMLl ], [XML]). 40 
[0015] HTML ermoglicht die formatierte Darstellung von Text (z. B. SchriftgroBe, Absatzformaie, Tabellen usw.) so- 
wie das Einbinden beiiebiger anderer Dateiformate (z. B. Bilder, Sound, Videos), 

[0016] Daruberhinaus besitzt HTML "Hyperlinks", also Sprungverweise zu anderen Seiten, die im HTML-Quelltext 
mit ihrer URL definiert sind. 

[0017] HTML und HTTP zusammen bilden das WWW (World Wde Web). Durch die in die Seiten eingebetteten Hy- 45 
perlinks erscheint dem Benutzer der Eindruck, er wurde auf einer Gruppe von Seiten "sich befinden", obwohl das HTTP- 
Protokoll keinen Verbindungsstatus kennt. Da die URL jeden beliebigen WWW-Server referenzieren konnen, erlaubt die 
geschickte Kombination von HTML-Seilen das Erstellen von " Applikationen", die sich iiber mehrere Servei; moglicher- 
we ise we ltweit verteilt, erstrecken. Durch die Einbindung von Ftogrammen, die auch (Ober HTTP-IDST Oder eine query 
in HTTP-GET) Benutzereingaben annehmen, lafit sich die Funktionalitat dieser "Web-Applikationcn" beliebig erweitem 50 
und viele gangige Benutzeroberflachen einer Software funktional nachbilden. 

2.2.1.5 ssl und ds 

[0018] Die Dateniibertragung in TCT/IP und damit auch in HTTP erfolgt grundsatzlich unverschliisselt und mit be- 55 
grenzter Hehlerkontrolle. Ein boswilliger Angreifer, der Zugang zu geeigneten Routem hat, kann den Datenverkehr ab- 
horen urid verfalschen. 

[0019] Um dies zu verfaindem, hat die Firma Netscape eine zusatzliche ProtokoUebene standardisiert, die als ssl (siehe 
[SSL2]) bekannt ist ssl setzt auf TCP auf und stellt der Applikation wiederum Sockets zur \ferfugung (ist also fiir die 
Applikation wahrend der Ohertragung wieder transparent), ermoglicht aber die Absicherung der Ubertragung mit. ver- 60 
schiedenen kryptographischen Methoden (symmetrische Schlussel, asymetrische mit ein- oder beidseiliger Authentifi- 
zierung) wie sie weiter unten beschrieben sind. 

[0020] SSL wurde in einer Erweiterung als TLS ([RFC 2246]) in die Internet-Standards aufgenommen. 

2.2.1.6 https 65 

[0021] https, auch S-HTTP genannt, ist in (RFC 2660] spezifiziert und stellt die Implementierung des http-ProtokoUs 
uber ssl- bzw. tls- Verbindungen dan Algoiithmen und Schnittstellen zur kryptographischen In&astruktur sind in den gan- 
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gigen Web-Servem- und -Browsem implementiert. 

2.2.1,7 Firewall 

5 [0022] Da das Internet als unschiitzbarer, offentlich^ Raum gilt, mussen die Zugange zu Netzen, die veitrauenswiir- 
dige Daten enthalten, entsprechend vor unbeiechtigtem Eindringen geschiitzt werden - veigleichbar der Pforte an einem 
Werkseingang. Die entsprechenden Vorrichtungen bezeichnet man als "Firewall". Einen Uberblick uber Techniken und 
Begriffe vermittelt [RFC 2647]. 

10 2.2.1.7.1 Firewall-Prinzipien 

[0023] Firewalls verwenden zwei Grundprinzipien: 

- Paketfilter: Es handelt sich bier um spezielle Router (vgl. Abschnitt TCP/IP), die zwischen dem extemen und 
IS dem intemen Subnetz stehen und nur nacb bestinunten Regeln, ausgebend von Quell- und Zieladressen der Pakete, 

eine Verbindung herstellen, abweisen oder umleiten. 

Paketfilter konnen nieist auch IP-Adressen umwandeln ("Network address translation" NAT oder "Masquwading'*). 

- Application-Level-Filter: Diese Filter treten gegeniiber den Kommunikationspartnem als Gegenstelle aus und 
werten den Inhalt der ubertragenen Dalen aus (z. B. Datentypen, Inhalt, Viren usw.). Je nach Ergcbnis der Auswer- 

20 tung wird der Inhalt dann transparent ubertragen, gesperrt, verandert oder auch nur der Transfervorgang protokol- 

lierL 

Neben Sicherheilsuberpriifungen konnen diese Rlter auch Dalen zwischenspeichem und werden dann als "Proxy"- 
Server bezeichnet, wobei derBegrifF auch synonym fur Application level filter verwendet wird. 
Application level filter mussen das jeweilige Protokoll (z. B. Mail, ftp, http. . .) verstehen, um den Inhalt analysieren 
25 zu konnen. 



2.2.1.7.2 FirewaU-Archilekturen 

30 [0024] Die Firewalls- Konaponenten werden zu "Firewall- Architekturen" kombiniert. Gangige Grundkonfigurationen 
sind: 

Einfacher Paketfilter: 

(Internet) <Paketfilter> (internes Netz) 

35 

Routing findet nur nach festgelegten Regeln statt. 
Es findet keine Inhaltsiiberprufung statL 
Einfacher Proxy: 

40 (Internet) <Proxy> (internes Netz) 

Es findet kein direktes Routing zwischen intemem Netz und Internet statt. 
Nur ProtokoUe, die ini Proxy implementiert sind, konnen ubertragen werden. 
Dreigliedrige Rrewall: 

45 

(Internet:) <Paketf ilter> (internes Netz) 

I 

(DMZ) 

+ — <Proxy> 

+ — <Web-, Mail-, ... -Server> 

50 

Zweistufige Firewall: 

( Internet ) <Paket f . 1> — + — <Paketf . 2>~ (internes Netz ) 

I 

55 (DMZ) 

+ — <Proxy> 

+ — <Web-, Mail-, ... -Server> 

[0025] Bei der dreigliedrigen und der zweistufigen Firewall wird zwischen Internet und intemem Netz eine "Entmili- 
tarisierte Zone" (engl. demilitarized Zone = DMZ) als eigenes Subnetz - gleichsam als Sich^4ieitsschleuse - geschaffen. 
60 [0026] Tnnerhalb der DMZ gelten niedrigere Sicherheit^sanforderungen als im intemen Netz., viele unberechtigte Zu- 
griffe aus dem Internet werden jedoch bereits von der ersten Paketfilterstufe abgefangen. 

[0027] In der DMZ befinden sich typischerweise die Proxy-Server zur Steuerung des 2^griffs zum interaen Netz sowie 
ggf. die dffi^tlichen Server der Organisation. 

65 ' 2.2.2 Kryptographie 

[0028] Die digitale Kryptographie lost unter Anwendung mathematischer (meist zahlentheoretischer) \^rfahren ver- 
schiedene Sicherhdtsanforderungen der digitalen Koimnunikation wahrend der Speicherung und/odert)l>ertragung, ins- 
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besondere • " 

- Schutz vor unberechligtem ZugrifiF von Daten durch Dritte 

- Schutz vor unberechtigier Anderung von Daien 

- Identjfikation und Authentifizierung von Sender und Empfanger 5 

- uberprijfbare Verbindlichkeit und Unwiderruflichkeit von elektronisch abgegebenen Erklaningen 

[0029] In der vorlicgenden Erfindung werden verschiedene eiablierte, im Folgenden erlauterle, Verfahren kombiniert. 
10030J Auf die tatsachlich erreichbare Sicherheit der Verfahren sowie deren EinfluBparaxneter (Schlussellange, organ- 
siatorische MaBnahmen, physikalische Sicherheit usw.) wird hier nur insofern eingegangen, als sie zum Verstandnis der lo 
Erfindung relevant sind. Alle Erlauterungen beziehen sich auf die Annahme nicht korrumpierter Systeme. 

2.2,2.1 symmetrische Verschlusselung 

[0031] Die einfachste Form der verschliisselten Dateniibertragung verwendet zur Ver- und Entschlusselung die gleiche 15 
Binarsequenz als Schlussel. Gangige Verfahren sind in DDES] und in [3DES] beschrieben. Eine verschlusselte Nachricht 
kann nur von jemandem, der liber den gemeinsamen Schlussel verfUgt, gelesen werden. 

[0032] WoUen mehrere Parteien vertraulich miteinander kommunizieren, so bestehi entweder (bei Verwendung eines 
gemeinsamen Schliissels) nur ein gemeinsamer vertraulicher Kommunikaiionsraum oder es muB fiir alle Kommunikati- 
onspaare ein eigener Schlussel vereinbart werden. 20 

2.2.2.2 Asymmetrische Verschliisselung 

[0033] Die symmetrische Verse hlusseiung erfordert eine vorab vorhandene verUrauliche Verbindung, um den Schlussel 
auszutauschen. Dies kann in der typischen elektronischen Kommunikation haufig nicht gewahrleistet werden. Diese Ein- 25 
schrankung uiiigehen asyiiuiietrische Verfahren. Dabei verfugt jede Parlei uber einen Ibil des Gesainlschlussels, beide 
Tcilc musscn (nach spczifischcn Kritcricn dcs Algorithmus) zusanuncnpasscn ("SchlCisscl-SchloB-Prinzip"). 
[0034] Eine Nachricht, die mit einem Schliisselteil verschlusselt wird, kann nur mil dem jeweils passenden Tfeil des 
Schlusselpaares entschlusselt werden. Die Reihenfolge, in der die Schlussel angewendet werden, ist dabei (zumindest bei 
RSA) gleichgultig, ebenso konnen mehrere Schlussel paare nacheinander angewendet werden. 30 

2.2.2.2.1 Algorithmen 

[0035] Bekannte Algorithmen fur asymmetrische Verschliisselung sind Diffie-Hellman ([RFC 2631] [US-Pat No. 
4,200,770]) und RSA ([RSA][RFC 2313] (als PKCS #1); [US-Pat No. 4,405,829]), DSA sowie Algorithmen auf der Ba- 35 
sis EUiptischer Kurven ([PKCS 1 3]). 

[0036] Soweit nicht anders angegeben, beziehen sich die folgenden Ausf iihrung auf RSA, sind aber weitgehend auf an- 
dere Algorithmen iibertragbar. 

2.2.2.2,2 Public-Private-Key- Verfahren . : . . 40 

[0037] Bei diesem Verfahren (oft auch mit PKI - Pubfic Key Infrastructure - referenziert) behalt jeder Teilnehmer an 
einem Kommunikationssy stem einen Schlussel des Paares, wahrend der andere an alle anderen Teilnehmer veroffentlicht 
wird. 

45 

2.2,2.2.2.1 Verschliissebi 



[0038] Zum Verschliisseln einer Nachricht gegen unberechtigtes I^sen verschlusselt der Sender mit dem ihm bekann- 
ten 5fFentlichen Schlussel des Empfangers. Nur dieser verfugt fiber den dazu passenden privaten Schltissel und kann die 
Nachricht entzifTem. SO 

2.2.2.2.2.2 Signatur (digitale Unterschrift) 

[0039] Der Sender verschlusselt seine Nachricht mit seinem eigenen privaten Schlussel. Jeder im System kann diese 
Nachricht lesen, da der dazugehorige Schlussel im Paar per Definition ofifentlich ist, 55 
[0040] Das Lesen mit dem ottentlichen Schlussel des Senders gelingt jedoch nur, wenn tatsachlich der private Schliis- 
sel des behaupteien Senders zum Verschliisseln verwendet wurde. Ein boswilliger DriUer, der sich mifibrauchlich als 
Sender ausgeben mochte, aber nicht iiber dessen privaten Schlussel verfiigt, kann dies nicht erreichen. Damit ist die Au- 
thentizitat des Senders gesichert. 

[0041 ] Der Sender kann eine einmal ahgegehene Nachricht nicht verleugnen, wenn sie enf7.iffert. werden konnte, da nur 60 
er in der Lage war, diese Nachricht zu erzeugen. 

2.2.2.2.2.3 Trust-Center 



[0042] Public- Key-Systerae erfordem, daB jeder Kommunikationspartner sich auf die Echtheit der von ihm verwende- 65 
ten offentlichen Schlussel verlassen kann. 

[0043] Im einfachen Fall kann das durch einen vorherigen Austausch mit dem Inhaber uber einen sicheren Kanal er- 
folgen. Der erforderliche Austauschaufwand steigt jedoch mit dem Quadrat der Teilnehmer und wird deswegen in gro- 
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Beren Systemen zu aufwendig. 

[0044] Fiir diesen Fall kann eine "Verirauenswurdige Slelle" (haufige Synonyme: Zerlifzierungsstelle, Netznotar, Cer- 
tificate Authority, Trust-Center) zwischengeschaltet werden. Der einzelne Nutzer tauscht nur mit dieser Stelle die 5flPent- 
lichen Schliissel iiber einen sicheren Kanal aus. Das Trust-Center "signiert" den offentlichen Schliissel der Benutzer und 
5 stellt so deren Integritat sicher. 

[0045] Die Verteilung der signierten olfentlichen Schliissel ("Zertifikale") kann durch den Benutzer selbst - z. B. mit 
einer Nachricht oder durch Veroffenthchung im Nutzerkreis - erfolgen. 

[0046] Tnist-Center-Zertifikate konnen auch kaskadiert werden ("Certificate Chain"), d. h. die Integritatspriifung er- 
folgt indirekt iiber ein Center, das dem betreffenden Nutzer gegenuber nicht direkt, sondem iiber ein weiteres 'ITrust Cen- 
10 ter authentifiziert wurde. Analog konnen zwei zunacbst unabhangige Trust-Center sich gegenseidg zertifizieren (Cross 
Certificate) und so die Benutzerkreise vereinigcn. 

[0047] Einzelheiten des ublichen (standardisierten) Verfahrens sind in [X.509] beschrieben, 

2.2,2.2.2.4 Varzeichnis-Dienste 

15 

[0048] Die Veroffentlichung der X-509-Schlussel kann in sogenannten " Verzeichnissen" nach PC.500] erfolgen, wie 
sie speziell fiir das Internet in [RFC 2459] und [RFC 2510] beschrieben sind. 

[0049] Das gangige Protokoli hierfUr ist LDAP [RFC 1777], insbesondere in der aktueUen Version LDAP v3 [RFC 
2251]. 

20 [0050] Diese Verzeichnisse sind als eigenstandige Serverdienste angelegt. Sie ermdglichen die Suche eines Kommuni- 
kationspartners nach verschiedenen Kriterien (unter anderem auch eines weltweit eindeutigen, hieraichischen Namens 
nach X.500-Konvention, auch als DN = "distinguished Name" bezeichnet). Die Hinterlegung von X.509-Zertifikaten in 
LDAP-Verzeichnissen ist Bestandteil der Spezifikation. 

25 2.2.2.2.2.5 Smart-Cards 

[0051] Empfindlichstc Angriffsstcllc fiir cin PKI ist der Zugriff Unbcfiigtcr auf cincn pri vatcn Schlusscl. Da cs sich da- 
bei nur um eine bin are Sequenz handelt, kann dieser Schliissel unbemerkt kopiert und von einem Angreifer v^^endet 
v^^erden (PC-Wartung, Verwendung in einem firemden Rechner, bosartige Software auf einem PC. . .). 
30 [0052] Um dies zu verhindem, konnen die privaten Schliissel auf unabhangigen Geraten gespeichert werden, die die 
erforderlichen Verschlusselungsoperationen durchfiihren, ohne daB der private Schlussel das C3erat verlafit, und die kon- 
struktiv uberhaupt nicht in der Lage sind, den privaten Schliissel auszugeben. Unter verschiedenen voigeschlag^en 
Bauformen hat sich hierzu die "Smart-Card" im Kreditkartenfonnat etabliert (siehc [ISO 7816]- 15). 
[0053] Das Datenblatt eines Beispielproduktes findet sich unter [SecurlD 31(X)]. 

35 

2.2.2.2.2.6 Biometrische Identifizierung 

[0054] Smart-Cards und ahnliche "Security Tokens" konnen entwendet oder vom Inhaber im guten Glauben ieichtfer- 
tig uberlassen werden. Biometrische Verfahren (z. B. Fingerabdruck, Iris-Muster) ermoglichen dagegen die eindeutige 
40 Identifizierung einer Person direkt anhand von Korpermerkmalen. 

[0055] AUerdings ist die Zuverlassigkeit biometrischer Verfahren von der Integritat der prufenden Systeme am Ort der 
zu identifizierenden Person abhangig (vgl. [Biometrics]). In der Remote-Authentifizierung kann ein Angreifer durch ein 
fingiertes System die Reaktion eines echten Systems vortauschen, ohne daB die zu identifizierende Person tatsachlich an- 
wesend ist. 

45 [Q056] Es bietet sich jedoch an, die Verwendung privater Schliissel auf Smart-Cards (oder anderai Tokens) mit biome- 
trischer Zugriffskontrolle zu sichem, so daB vor jeder Verwendung des privaten Schliissels ein willentlicher Akt des In- 
habers vorausgehen muB (Vergleiche auch [ISO 7816]-11 bzw. zugehorige Normierungsentwurfe). 

2.2.2.3 Hybrid-Verfahren 

50 

[0057] Asymmetrische Verfahren erfordem aufgrund ihrer Komplexitat wesentlich hoheren Rechenaufwand als sym- 
metrische Varfahren. Dies wird durch die Verwendung von (meist sehr minimaUstischen) Tokens wie Smart-Cards welter 
VCTScharft, die im Gegensatz zu modemen Prozessoren in Anwendungsrechnem nur einen sehr begrenzten Datendurch- 
satz aufweisen. 

55 [0058] In vielen Einsatzgebieten werden deshalb verschiedene \^ahren kombiniert, um den Datendurchsatz zu opd- 
mieren. 

2.2.2.3.1 Session Keys 

60 [0059] Etn "Session Key" ist eine Zufallszahl, mit der unter Anwendung eines symmetrischen Verfahrens der GroBteii 
des Xommunikationsinhaltes verschliisselt wird. 

[0060] Das asymmetrische Verfahren (und ggf . das minimalistische Token) braucht dann nur mehr den Session Key 
verschiusseln. Dieser verschlusselte Session Key wird zusammen mit der (symmetrisch) verschliisselten Nachricht ubcr- 
tragen. Der Empfanger entschlusselt zunacbst den Session Key und mit diesem dann den Rest der Nachricht 

65 

2.2.2.3.2 Hash-Funktionen 

[0061] Hash-Funktionen sind sogenannte Einweg-Funktionen, die aus einer langeren Datensegenz einen (im statisti- 
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schen Rahinen) vergleichsweise kurzen, aber eindeutigen Wert (vergleichbar einer Ptufsumme) ermittelh, der oft auch 
als "Fingerprint" Oder "Hash- Wert" bezeichnet wird. Umgekehrt ist es jedoch nicht mdglich, aus der "Prtifsumme" auf 
die Daten selba* zu schlieBen. 

[0062] Gangige Algorithmen sind bekannt unter den Namen MD2, MD4, MD5 (siehe hierzu [RFC 1321 ]) oder [SHA]. 
Die Anwendung von Hash-Funktionen findet. sich etwa als HMAC unler [RFC 2104]. 5 

2.2.2.3.3 E-Mail und S-MIME 

[0063] Das Verschlussein und Signieren von elektroni schen Nachrichten als H-Mail isl weit verbreitet. AUe gangigen 
e-Mail-Progranune verfugen uber die enisprechende Technologies Die Technologie und InfrasU-uktur ist ausgereifl und lo 
kann als "Musterlosung" fur die Implementierung komlexer kryptographischer Verfahren gelten. 

[0064] Die Details des Standards "S-MIME" fiir verschlusselte Uberlragung von e-Mails im Internet sind in [RFC 
1421], [RFC 1422], [RFC 1423] und [RFC 1424] festgelegt 

2.2.2.4 Authentifizierungs-TokCT is 

[0065] In alien verteilten Rechnersystemen (meist Client-Server-Systeme) ist eine Authentifizierung des Benutzers am 
Zielrechner erforderlich. Im einfachen Fall authentifizierisich derBenutzer (typischerweise miiBenutzername und Pass- 
wort) an jedem Zielsystem einzeln. Bei groBeren Systemen fiihrt das zu einem erheblichen Administrationsaufwand im 
System und zur Verwirrung der Benutzer mit vielen Passwortem. 20 
[0066] Authentifizierungsverfahren mit einem eigenstandigen Priif system sind seit langerem bekannt. Bei diesen Ver- 
fahren existiert neben der datenanfordemden Stelle (z. B einem Aibeitsplatzrechner, also dem Client) und der datenhal- 
tenden Stelle (z. B. einem Fileserver) ein eigener Authentifizierungsrechner. Der Client meldet sich zunachst am Authen- 
tifizierungsrechner an, nur dieser muB in der Lage sein, die Identitatspiifung fur jeden Nutzer voizunehmen. Er erstellt 
dann ein "Token" oder "Ticket** nach kryptographi schen Methoden, das an den Client zuriickiibermittelt wird. Mit die- 25 
sem Token kann der Client sich dann an verschiedenen Datenservem authenlilizieren. 

2.2.2.4.1 Kerberos 

[0067] Als Prototyp der Token-basierten Authentifizierung gilt das am MIT entwickelle Kerberos, das in seiner aktu- 30 
ellen ^Version V5 als Internet-Standard ([RFC 1510]) etabliert ist. Eine Kerberos- Vari ante wird unter anderem auch im 
Microsoft-Betriebssystem WINDOWS 2000 eingesetzt und lost dort einen proprietaren Mechanismus, wie er in NT 4 
verwendt wurde, ab. 

[0068] Kerberos verwendet symmetrische Schlussel fiir jeden Benutzer, die in den Authendfizierungsrechnern abge- 
legt sind. 35 

2.3 Problemsiellung 
2.3.1 Konkrete Aufgabenstellung im medizinischen Umfeld 

40 

[0069] Ein Arzt behandelt einen Patienten und braucht dazu Daien (z. B. Befund, Rontgenbild. . .), die von einem Drit- 
ten (z. B. einem Krankenhaus, einem Labor oder ciner anderen Aiztpraxis) - "Datenhalter" genannt - gespeichert wcr- 
den. 

[0070] Verschiedene Rechtsvorschriften, Berufstandsregeln, Vertrauenserwartungen der Patienten, Vertrauenskonstcl- 
iationen usw. verpflichten den Datenhalter, nur berechtigten Personen einen Zugriff auf definierte und von den jeweiligen 45 
Personen abhangigen Bereich der Daten zu gewahren. 

[0071] ErforderHche Informationen, die der Datenhalter braucht, urn 2^griffsentscheidungen zu treffen, sind etwa: 

- Isl die anfordemde Person tatsSchlich Arzt und wenn ja, in welchem Fachgebiet? 

- Ist der Patient, den die Daten betreffen, anwesend und hat er seine Zustimmung erteilt? 50 

- Ist sich der Patient uber die gespeicherten Daten im Einzelnen bewuBt (will er z. B. einem Arzt, der ihn im Auf- 
trag einer Versicherung untersucht, ofiFenbaren, daB es umfangreiche Daten aus einer Herzklinik gibt)? 

- Gibt es eine besondere Vertrauensstellung zwischen der anfordemden Stelle und dem Datenhaltei; z. B.- aufgrund 
besonderer vertraglicher Regelungen? 

[0072] Die Anwendung der gebotenen hochsicheren UberU-agungsvertahren nach dem Stand der Ifechnik uberfordert 
regelmafiig die beteiligten Parteien, so daB die Absicherung der Ubertragung an Dritte ("sicherheitsvermittelnde Stelle") 
auszulagem ist, die jedoch keine Berechtigung haben, die Daten selber zu lesen. 

[0073] Kosten- und Eflizienzkriterien erfordem, daB auf Seiten des Datenhalters und der sicherherheitsvermittelnden 
Stelle die Abwicklung ohne direkte TunfluBnahme von Menschen erfolgt 60 
[00741 Neben der reinen Authentifizierung der beteiligten Personen konnen noch weitere Informationen des Anforde- 
rungskontextes erforderlich werden, die ggf. iteradv abgefragt werden mussen. 



2.3.2 Verailgemeinerung der Problernsteilung 

[0075] Die dargestellte Losung belrifft die Verschlusselung der Dbertragungswege und beinhaltet keine Einschrankung 
der Daten selber, deswegen kann der Einsatz auch auBerfaalb des medizinischen Umfeldes erfolgen. 
[0076] Damit kann die Aufgabenstellung erweitert werden: 



65 
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Es sou einem datenverarbeitenden System ermoglicht werden, bei einem angeforderteivDatenzugrifFInformationen uber 
den Kontext des beabsichtigten Zugriffs, insbesondere mehrerer beteiligter Personen, des Zeitpunktes, und ggf. weiteier 
anwendungsspezifischer Infonnationen zu erhalten. Der Betrieb des ZugriflFskontioUsystcms soU dabei von der Daten- 
haltung entkoppelt werden konnen. 

s 

2 A Wesen der Erfindung 

[0077] Es werden die bekannten Sicherheits- und Authentifizierungsverfahren deigestalt kombiniert, daB zur Authen- 
tifizierung eines Datenzugnffs mehrere Personen zustimmen mussen, weitere lnf<wmationen autgenommen werden kon- 
10 nen und die RoUen verschiedener Schritte im Authentifizierungsprozess i^umlich und datentechnisch weiteehend ent- 
koppelt sind. ^ 

[0078] Daniit wird es moglich, die Verteilung der Verantwortung fiir Teilbereiche ortlich und organisatorisch zu tren- 
nen und Systeme auf unterschiedlichen Plattfomnen zu integrieren. 

2.5 Gewerbliche Anwendbarkeit 

[0079] AUeine im Gesundheitswesen wird von Fachleuten ein enormes Rationalisierungspotendal sowie eine Quali- 
tats- und Serviceverbesserung vorhergesagt, wenn die Kommunikation zwischwi mehreren Arzten, die einen Patienten 
behandeln, verbessert wird. 

20 [0080] Die eleku-onische Kommunikation, wie sie in vielen anderen Bereichen heute bereits iibUch ist, konnte dafur ei- 
nen wichUgen Beitrag leisten, scheiterte bisher aber an einer Infrastruktur, die einerseits die erforderlichen Sicherheits- 
anforderungen erfiillt und andererseits fiir die betroffenen Akteure handhabbar bleibt. 
[0081] Die beschriebene Erfindung kann als Grundlage fur diese Sicherheits-Infrastruktur dienen 
[0082] Weitore AnwendungsfaUe ergeben sich z. B. in der Rechtspfiege, der Wirtschafts- und Steuerberatung der Per- 

25 sonalvenmtttung und -beratung, dem Versicherungswesai, dem Handel mit Kauferprofilen oder dem Finanzwesen. 

2.6 Vortcilc 

[0083] Bisherige Losungen auf bekannten Standards ermoglichen immer nur die Authentifizierung einer Person (z. B 
30 des Arztes). Dieser hat dann Zugriflf auf einen wesentlich groBeren Datenbestand, nicht nur auf den jeweiHgen Patienten* 
was hier emgeschrankt werden kann. Dutch die Ubertragung weiterer Kontextdaten konnen beKe^ig komplexe Sichcr- 
neitsphilosophien implementiert werden. 

[0084] Ein weiterer Vorteil der beschriebenen Losung ist die Modularitat. Es konnen damit einfach bestehende Sy- 
steme verschiedener Datenhalter und Datenverwender mit einf achen Schnittstellen kombiniert werden zu einem sicheren 
35 Datenaustauschnetzwerk. 

2.7 Ausfiihrungsbei spiel 

siehe Abschnitt 3 

2.8 lit^atumachweis 



40 
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Triple Data Encrypticm Algorithm Modes of Operation. 
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[Biometrics] 

Gael Hachez, Fran9ois Koeune and Jean- Jacques Quisquater Biometrics, access control, smart cards: a not so simole 
50 combination *^ 

^g// www.dice.ucLac.be/crypto/publications/Biometrics.pdf 
American National Standards Institute 

American National Standard for Infonnation Systems - Data Link EncrvDtion 
55 ANSI X3. 106; 1983 
IHTMI^IOIJ 
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HTML 4.01 Specification 
W3C Recommendation; December 1 999 
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nS07816] 
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http://siLgmd.de/SICA/papers/WS_01/Beitras_Meister 
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RSA Laboratories _ - 

PKCS #13: Elliptic Curve Cryptography Standard PROJECT OVERVIEW January 12, 1998 
hup:// www.rsasecurity.com/rsalabs/pkcs/pkcs-l 3/project_overview.htiTil 
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J. Postel ~ ISI 

User Datagram Protocol 
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DARPA Internet Program Protocol Specification Internet Protocol lo 
RTC 791; September 1981 
[RFC 793] 

DARPA fntemet Program Protocol Specification 
Transmission Control Protocol 

RFC 793; September 1981 15 

[RFC1034] 

Mockapetris, P 

Domain Names - Concepts and Facilities 

RFC 1034, November 1 987 . , 

[RFC1035] 20 

Mockapetris, P. 

Domain Names - Implementation and Specification" 
RFC 1035, November 1987 
[RFC 1321] 

Rivest, R. 25 
The MD5 Message-Digest Algorithm 
RFC 1321; April 1992 
[RFC 1421] 
Linn, J. 

Privacy Enhancement for Internet Electronic Mail: 30 
Part I: Message Encryption and Authentication Procedures 
RFC 1421 ; DEC, February 1 993 
[RFC 1422] 
Kent, S. 

Privacy Enhancement for Internet Electronic Mail: 35 
Part IT: Certificate-Based Key Management 
RFC 1422; BBN, February 1993 
[RFC 1423] 
Balenson, D. 

Privacy Enhancement for Internet Electronic Mail: 40 
Part ni: Algorithms, Modes, and Identifiers 
RFC 1423; TIS, February 1993 
[RFC 1424] 
Balaski, B. 

Privacy Enhancement for Internet Electronic Mail: 45 

Part IV: Notary, Co-Issuer, CRL-Storing and CRL-Retrieving Services 

RFC 1424; RSA Laboratories, February 1993 

[RFC 1510] Kohl, J. and B. Neuman 

The Kerberos Network Authentication System (V5) 

RFC 1510; September 1993 50 

[RFC 1738] Bmiers-Lee, T, Masinter, L., and M. McCahiU 

Uniform Resource Locators (URL) 

RFC 1738; December 1994 

[RFC 1777] Yeong, Y, Howes, T. and S. KiUe 

Lightweight Directorv Access Protocol 55 

R>C 1777; March 1995 

[RFC 1 866] Berners-Lee, T. and D. Cbnnolly 

I lypertext Markup Language - 2.0 

RFC 1866; November 1995 

[RFC1883] 60 

Deering, S. and R, Hinden 

Internet Protocol, Version 6 (IPv6) Specification 

RFC 1883; December 1995 

[RFC 1945] 

Bemers-Lee, T., Fielding, R. and H. Frystyk 65 
Hypertext TVansfer Protocol - HTTP/LO 
RFC 1945; May 1996 
[RFC 2104] 
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Krawczyk, H., Bellare, M., and R. Canetti 
HMAC: Keyed-Hashing for Message Authentication 
RFC 2104; February 1997 
[RFC 2246] 
5 Dierks, T, and C. Allen 

The TLS Protocol Version 1.0 
RFC 2246; January 1999 
[RFC 2251] 

M. WahL T. Howes, S. Kille 
10 Lightweight Directory Access Protocol (v3) 
RFC 2251; December 1997 
[RFC 2313] 
Kaliski, B. 

PKCS #1: RSA Encryption Version 1.5 
15 RFC 2313; March 1998 
[RFC 2396] 

Bemers-Lee, T., Fielding, R. and L. Masinter 
Uniform Resource Identifiers (URI): Generic Syntax" 
RFC 2396; August 1998 
20 [RFC 2459] 

Housley, R., Ford, W., Polk, W. and D. Solo 

Internet X.509 Public Key Infrastructure Certificate and CRL Profile 
RFC 2459; January 1999 
[RFC 2510] 

25 C. Adams, S. Farrell 

Inlemel X.509 Public Key Infrastructure Certificate Management Protocols 
RFC 2510; March 1999 
[RFC 2616] 

Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L. Leach, P. and T. Bemers-Lee 
30 Hypertext Transfer Protocol - HTTP/1 . 1 
RFC 2616; June 1999 
[RFC 2631] 
Rescorla, £. 

Diffie-Hellman Key Agreement Method 
35 RFC 2631; June 1999 
[RFC 2647] 

D. Newman 

Benchmaridng Terminology for Firewall Performance 
RFC 2647; August 1999 
40 [RFC 2660] 

E. Rescorla, A. Schiffman 

The Secure HyperText Transfer Protocol 

RFC 2660, August 1999 

[RFC 2854] 
45 D. Connolly, L. Masinter 

The "text/html" Media Type 

RFC 2854; June 2000 

[RFC 2965] 

D. Kristol, L. MontuUi 
50 HTTP State Management Mechanism 

RFC 2965; October 2000 

[RSA] 

R. Rivest, A. Shamir, and L. M. Adleman 

A Method for Obtaining Digital Signatures and Public-Key Cryptosystems Communications of the ACM, v. 21, n. 2, Feb 
55 1978, pp. 120-126. 
[SecurID3100J 

RSA SecurID<» 3100 Smart Card 

Secure RSA Cryptographic Container for PKI Credentials (Datasheet) 
http:/ / www-rsasecurity.com 
60 /products/securid/datasheets/ds3l O0smartcard.html 
[SHA] 
NIST 

Secure Hash Standard 
FIPS PUB 180-1; April 1995 
65 [SSL2] 

Hickman, Kipp 
The SSL Protocol 

Netscape C^ommunications (^oip., Feb 9, 1995 
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[US-Pat No. 4,200,770] „ ' ^ 

Cryptographic Apparatus and Mclho(i ("Di Ilic-F Icll man") 
[US-Pat No. 4,218,582] 

Public Key Cryptographic Apparatus and Mcihcxi (**IIclItnan-Merk]e") 

[US-Pat No. 4.405,829] 5 
Cryptographic Communications System and MclhcxI ("RSA") 
[US-Pat No. 4,424,414] 

Exponential Cryptographic Apparatus and Mclhcxl ("ncllnian-Pohlic") 
IX.500J 

Information Technology - Open Systems Inicrconncciion - ITic Directory: Overview of concepts, models and services lo 
ITU-T Recommendation X.500 
ISO/EEC 9594-1; 1997 
(X.501] 

Information Technology - Open Systems Interconnection llic Directory: Models 

ITU-T Recommendation X.501 , - 

ISO/IEC 9594-2; 1997 

[X.509] 

Information Technology - Open Systems Interconnection 

The Directory: Authentication framework 

ITU-T Recommendation X.509 

ISO/EC 9594-8; 1997 

[X.520] 

Information Technology - Open Systems Interconnection ITic Directory: Selected attribute tvoes 
ITU-T Recommendation X.520 " 

ISO/EC 9594-6; 1997 ^3 
[X.680] Absuract Syntax Notadon One (ASN. 1) - Spccificaiion of Basic Notation 
ITU-T Recommendation X.680; 1994 
[XHTMLl] 

Steven Pemberton et. al. 

XHTML 1.0: The Extensible HyperText Markup Language: 30 

A Reformulation of HTML 4 in XML 1.0 

W3C Recommendation, January 2000 

http:/ / www.w3.org/TR/xhtmI 1 

[XML] 

Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler 35 
Extensible Markup Language (XML) 1 .0 (Second Edition) 
W3C Recommendation; 6 October 2000 
hftp:/ / www. w3.orgArR/REC-xml 

3.1 Vorbemerkung 4q 

[0085] Das beschriebene Ausfiihrungsbeispiel beruht auf der konkreten Aufgabenstellung im medizinischen Kontext 
(vgl. Erlauterungen zum PatentanU-ag) und verwendet deshalb die entsprechenden Begriflfe "Arzt", "Patient" usw. Die zu- 
gnmde liegende Aufgabenstellung besteht darin, dem Arzt Zugriff auf vertrauliche Daten des Patienlen, den er gerade 
behandelt, zu gewahren, und zwar nur zu diesem Patienten und nur in einem Umfang, wie es seiner standesrechtlichen 45 
Zulassung und der Einwilligung des Patienten entspricht (vgl. Anspruch 1). 

[008<q Mogliche Erweiterungen und Varianten des Verfahrcns sind teilweise (in Kursi vdruck) im Text sowie im letzten 
Abschnitt beschrieben, ergeben sich aber insbesondere aus den Patentanspriichen. 

3.2 Architektur 50 

[0087] Die an einem Gesamtsystem beteiligten Komponenten sind in der S^eichnung 1 skizziert. 
[0088] Es wird fur die drei wesentlichen Bestandteile - Anforderungsstelle, ZugrififskontroUe und Datenhaltung - im- 
mer im Singular gesprochen. In einem ausgebauten System konnen natiirlich von all diesen Stellen mehrere Instanzen 
auftreten, die auch miteinander weiter vemetzt (z. B. uber HTML-Links) sein konnen. 55 

3.2.1 Aibeitsstauon zur ZugrifTsanforderung 

[0089] Am Arbeitsplatz des Arztes befindet sich ein VC mil einem Standard- Web-Biowser. Es wird angenommen, daB 
der Zugnff auf die Daten vorzugsweise iiber HTMIThltp erfolgt, da damit eine einfache Integration und Standardisierung 60 
eneicht werden kann. 

[0090] Erganzend kann an der Arztpraxis auch ein eigenes Praxis-Managent-System ("PMS") vorliegen, das entweder 
uber den Browser oder unabhangig, aber sinnvoUerweise auch uber htlp^ttps Daten nach Freigabe abrufen kann. Die In- 
tegration des PMS ist jedoch fur das Verstandnis der vorUegenden Erfindung unwesentlich. 

[0091] Die Zuverlassigkeit des PCs und der Praxissoftwaie unterliegt der KontroUe des Arztes. 65 
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3.2.2 Schiusseikarten der Benutzer 

[OOS^] Sowohl Arzt als auch Patient verfiigen iiber einc Smart-Card mit dort abgelegtem privatem Schlussel und inte- 
griertem Kryptoprozessor (nach Anspruch 7 und 8). 
5 [0093] Fiir Arzte gibt es dafur bereits einen etablierten Standard ("health professional card" - HPC), der diese \brga- 
ben erfiillt. 

[0094] Fiir die Patienten gibt es keinen definierten Standard. Die Karte des Patienten sei mit einem Fingerabdruckleser 
ausgestattet, der vor jeder Verschliisselungsaktion ausgelost werden muB und dafnrsorgt, daB vor jeder Schlusseiverwen- 
dung eine explizile, personliche WillensauBerung des Patienten vorliegt (Anspruch 9 und 10). 
10 [0095] Die Arbeitsstation des Arztes muB init geeigneten Lesegeraten ausgestattet sein, um die Smart-Cards (gleich- 
zeitig Oder nacheinander) anzusteuem. 

3.2.3 Zugriffskontrollsysfem 

15 [0096] Das Zugriffskontrollsystem ("Access Management Hub") befindet sich raumlich und oiganisatorisch unabhan- 
gig von Arztpraxis und Datenbank. 

[0097] Es ist iiber eine Firewall mit dem Internet verbunden. 

[0098] Es verfugt iiber eine Datenbank der offentlichen Schliissel aller registrierten Arzte sowie aller Zertifizierungs- 
stellen, die zur Registrierung von Patienten befugt sind (Access directory). 
20 [0099] Diese Datenbank kann am Standort der ZugriflFskontrollstelle selbst liegen oder iiber geeignete Directory-Pro- 
tokoile (z. B. LDAP) ganz oder teilweise von anderen Standorten importiert werden (vgl. Anspruch 21 flf). 

Erweiterung 

25 [0100] Werden - abweichend vom Bild - mehrstufige Zertifikatsketten verwendet (vgl. Anspruch 18), reicht es fur die 
priifende Stelle aus, die Zertifikate der untersten Ebenen der verwendeten Ketten vorzuhalten. In dieseiii Fall iiiussen die 
voUstandigcn Zertifikate cinschlicBlich ggf. aller Zwischcnzcrdfikatc auf den Smartcards der zu authcntifizicrcndcn Pcr- 
sonen abgelegt sein und als Bestandteil des Authentifizierungsantrages mit iibertragen werden (Anspruch 20). 
[0101] Die ZugriffskontroUs telle stellt das empfindlichste System in der Sicherheitskette dar und befindet sich deshalb 

30 in einem eigenstandigen hochsicheren Bereich eines spezialisierten Dienstleisters ("Access security provider"). 

Erweiterung 

[0102] AUe Vorgange konnen - z, B. zur Beweissicherung in Streitfallen - niitprotokolliert werden ("Access Log"). 

35 

Erweiterung 

[0103] Die ZugriffskontroUstelle kann bo^eits Infonnationen vorhalten, wo welche Daten iiber einen Patienten abge- 
speichert sind ("lxx:ation directory") 

40 

3.2.4 Datenspeicher 
[0104] Die Datenbank mit Patientendaten wird als bestehend angenommen. 

[0105] Die Schnittstelle fiir Femzugriff sollte moglichst nahe an die Anforderung browseigestiitzter Systeme kommen, 
45 was beispielsweise durch die Anwendung der XML- Version des intemationalen Patientendatenstandatds "hl7" erreicht 
werden kann. 

[0106] Der Datenspeicher ist aus dem Internet nicht direkt erreichbar (Anspruch 39). 

3.2.5 Fieigabesystem 

50 

[0107] Das Freigabesystem ("ZugrifFskontrollserver") befindet sich hinter einer Firewall (Anspruch 39) am Standort 
des Datenhalters, z. B. eines Krankenhauses ("Hospital or other maintainer of health information services"). 
[0108] Im Beispiel wird angenommen, daB die Datenbank selber Infonnationen im XML-FcMnmat liefert, das von den 
gangigen heutigen Browsem nur eingeschrankt gelesen werden kann. In diesem Fall kann das Fieigabesystem eine Ober- 
55 setzung ("XSLT-PtocessOT") in Standard-HTML vomehmen. Es konnen aber auch XML-Daten direkt duichgereicht 
werden (nach ertblgta- Freigabe) od«; wenn die Datenbank selbst ITl'ML-Format liefem kann, kann auch dieses nach 
PrUfung weitergereicht werdwi. Durch diese Variationsmoglichkeiten ergeben sich breite Anpassungsmoglichkeiten an 
vorhandene Systeme. 

[0109] Fiir die Implementierung kann jede gangige Progranunierumgebung verwendet werden. Java-Servlets bieten 
60 beispielsweise die erforderlichen HTTP-Schnittstellen und sind ofFen fiir die wichtigen Netzwerk-, Krypto- und XMI.- 
Bibliotheken. 

[0110] Der Zugriff auf den Datenspeicher erfolgt typischerweise nochmals iiber eine Paketfilterung auf IP- und Port- 
Ebene (dicke sch warze linie mit Lochem), so daB sich das Freigabesystem in einer DMZ zwischen zwei Paketfiltem be- 
findet (vgL "Stand der Technik/Enrewall" sowie Anspruch 39 und 40). Aitemativ, aber mit gleicber Funktionalitat, erfolgt 
65 die Kommunikation zwischen Firewall und Datenbank iSber ein anderes Ptotokoll als TCP/IP, so daB ein direktes Routing 
aus dem Internet eflizient verhindert wird. 

[OIU] Das Freigabesystem erhalt iseine ZugriflFskontrollinformationen aus der Datenbank (Anspnich 30 ff, im Bild an- 
gedeutet mit dem dicken Doppelpfeil), wobei die genaue Implementierung davon abhangt, wie diese Informationen vor- 

12 
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liegen. Eine einfache Moglichkeil besleht darin, daB die Zugritfskonirollinformationen zusammen mil den Daten (An- 
spruch 32), eiwa ini HTML-Header als Meta-Tags (Ansprucb 33) Oder ais spezifische Felder in einem XML-Formai (An- 
spruch 34) abgelegt sind. 

3.2.6 Datenubertragung 5 

[0112] Die Datenubertragung erfolgt im Beispie] ausschlieBlich uber das Internet (vgl. Ansprucb 2), also zunachst un- 
sicher. 

10113J Alle Verbindungen werden uber ssU also verschlussell, realisiert (Anspruche 16, ggf. 2 K 26/27, 36). Dabei er- 
folgt inimer eine wechselweise Aurheniifizierung (also sowohi Server gegeniiber Client als auch Client gegenuber Ser- lo 
ver), um einen hochsunoglichen Schutz gegenuber Angreifem zu gewahren. 

[0114] Die Ablaufe sind so gestaltel, daB das einfache http-ProtokoU mit Request -Response-Zyklen ausreicht. Somit 
kann an alien Verbindungen das standard! si erte hUps-ProrokoIl (http uber ssl) verwendet werden (Anspruche 17, 27, 36). 
[0115] Erweiterungen und Variationen der Netzwerkprotokolle sind an dieser Stelle zwar denkbar, versprechen aber 
keinen funkdonalen Vorteil. 15 

3.2.7 Trust-Center 



[0116] Im beschriebenen Ablauf sind eine Rcihe von asymmetrischen Schlusselpaaren im Einsatz, und zwar minde- 
stens: 



3.3.3 Datenauswahl 



3.3.4 Datenabruf 

[0125] Im Idealfall verhalt sich das nun geofifnete System gegenuber dem Arzt wie cin Satz von HTML-Sciten, er kann 
also im Bestand der Padentendaten mit seinem Web-Browser "surfen" (Ansprucb 41 ff) und ggf. wicbtige Informationen 
in sein eigenes Praxisdatensystem "downloaden". 



20 



- Scblussel des Arztes auf der HPC (Anspruch 1) 

- Schliissel des Patienten (Anspruch 1) auf seiner biometrisch gesicherten (Anspriicbe 9, 10) Karte 

- ssl-Client-Schlussel des Arzt-Arbeitsplatzes (Anspruch 16 und 35) 

- ssl-Server-Schlussel des Zugriffskontrollsys terns (Anspruch 16 und 26) 25 

- ssl-Server-Schlussel des Freigabesy stems (Anspruch 26 und 35) 

- ssl-Clicnt-Schlusscl des ZugriffskontroUsystcms (nacb Anspruch 24 und 26) und/odcr des Frcigabcsystcms (nach 
Anspruch 25 und 26) 

[0117] Diese Schliissel werden sinnvollerweise von einem Trust-Center als spezialisiertem Dienstleister generiert und/ 30 
Oder in ihrer Echlheit bestatigt (Anspruch 10). Inwieweit hierbei ein einziges oder mehrere Trust-Center verwendel wer- 
den, und ob diese organisatorisch an einer der dargestellten Stellen, z. B. der Zugriffskontrollstelle, angelagert sind, ist 
aus tecbniscber Sicht nicht von Belang. 

3.3 Ablauf aus Benutzersicht 35 
3.3.1 Antragssoftware 

[0118] Wenn der Aizt seine Bebandlung aufnimmt, ladt oder aktiviert er eine geeignete "Antrags-Software" (z. B. ein 

im Browser lauffahiges Java-Applet; "Authorisierungs-Applet" im Bild), die auf seinem Rechner vorinstalliert ist oder 40 

die er aus einer verUrauenswiirdigen Quelle (z. B. auch der Zugriffskonu-ollstelle) beziehen kann. 

3.3.2 Freigabeantrag 

[0119] Die Antragssoftware verlangt nun nach den Idendtatsbeweisen, also etwa den Smart-Cards von Arzt und Pa- 45 
tient. Die endgultige Zustimmung (nach Anspruch 1) erfordert noch die Freigabe des Schlussels auf den Karten, z.B. 
durch ein Pass wort bei der HPC und durch den Fingerabdruck bei der biometrischen Padentenkarte. 
[0120] Nacb Absenden des Freigabeantrags (nadi Ansprucb 3) an die Zugriffskontrollstelle meldet diese entweder ei- 
nen Authentifzierungsfehier oder einen Hyperlink zum nachsten Schritt. 

[0121] Der in Zeichnung 2 auf Seite 52 dargestellte Bildschirmabzug zeigt eine Pilotversion eines solchen Freigabe- 50 
applets, bei dem die Smart-Cards durch Binarsequenzen ersetzt sind, die iibcr die \S^ndows-Zwischenablage in entspre- 
chende Fenster eingefiigi werden ("paste doctor's/patient's key here"). 

[0122] Die Freigabe selbsi erfolgt in der Pilotversion durch Passworter, was im Bild beim Padenten bereits erfolgt ist 
("open*') und fur den Arzt noch abgefragt wird ("please enter password") 



55 



[0123] Im Beispiel wird angenommen, daB die Zugriffskontrollstelle bereits uber eine Liste von zum Patienten verfiig- 
baren Daten verfugt. In diesem Fall kann an den Arbeitsplatz des Arztes eine entsprechende Liste als HMTL-Seite mit 
Hyperlinks versandt werden, wobei die Hyperlinks auf die jeweiligen Freigabeserver verweisen. 60 
[0124] Arzt und/oder Padent wahlen (ggf. gemeinsam) die abzurufenden Daten aus ("weitere KontexdnformaUonen" 
nach Anspruch 1). 



65 
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Erweitening 

[0126] Bei geeigneter Datenstniktur konnen dabei auch Querverweise zwischen verschiedenen Datenbestanden auftre- 
ten. Ggf. wird das System nach einer emeuten Authentifizierung verlangen, wenn etwa der Bereich einer anderen Zu- 
5 griffskontrollstelle betreten werden soli oder der Patient weitergehende Freigaberechte fur besonders vertrauenswurdige 
Daten oder weitere Rechte (z. B. Schreibzugriff) erteilen soil. 



3.4 Zusammenspiel der kryptographischen Komponenten 

10 [0127] Die erforderlichen kryptographischen Ablaufe soUen bei erfolgreicher Authentifizierung weitgehend im Hinter- 
grand ablaufen. Lediglich bei einem Authentifizieningsfehler sollen Fehlermeldungen soweit aussage^hig sein, daB Be* 
dienungsfehler behoben werden konnen. Allerdings diirfen Fehlermeldungen keine wertvollen Informationen an poten- 
tielle Angreifer offenbaren oder bereits vertrauenswiirdige Daren (bzw. deren Existenz) preisgeben (falsch ware z. B. 
"Sie sind nicht berechtigt, auf den Datenbestand der Sucht-Heil-Klinik zuzugreifen"). 

15 

3.4.1 Schliissel 



[0128] Das Format der Schlussel entspricht dem X.509-Slandard, wie es von g^gigen Intemet-Browsem verstanden 
wird. (Beispiel: siehe Zeichnung 3 ) 
20 [0129] Die Schlussel fur https miissen dabei direkt vom Browser verstanden werden konnen. Fiir die Smart-Card- 
Schlussel ist dies nicht unbedingt notwendig, da sie uber die Authentifizierungssoftware angesprochen werden. Die \^r- 
wendung standardisierter Formate ermoglicht aber den Zugriff auf vorhandene, getestete Softwarebibliotheken zur Er- 
zeugung und Verarbeitung der kryptographischen Daten. 

[0130] Ein Schlusselpaar, das aus einem Browser im PKCS#12-'Format ([PKCS12]) exportiert wird, stellt sich zu- 
25 nachst folgendermaBen dar: 



BEGIN RSA PRIVATE KEY 

Proc-Type : 4 , ENCRYPTED 

DEK-Info: DES-EDE3-CBC, FD4DCOA4 919C7342 
ihPltydbSKnDUpgDSsMh^^ 

BG02JwyedknWcYM6t0hFAniRX9GL2bh/MhZEBQP80cUQhVBvV0oek9LIlW84Y+czD 
QdwmrP2inNgScRr5cy6Rw/3TleYvasdZufL38LwMpxwU3mOccTXgNr8w4wcGOMfA6 
kVzbZMxunLPYQS5FekxLn8K7Ce/WKXEiamTvLGlVaAd6mhE9vKKBlwk 
F2LOur/Yg5gX8cLkC9L6cY7B8LSJ5z5C9HJG3F4553o= 

END RSA PRIVATE KEY 

Bag Attributes 

friendlyNane: Benjamin Blymchen's IP-Web ID 

localKeylD: 3C E3 30 30 57 B7 49 A9 CI A8 AA CD 04 B3 48 CC EC F5 24 02 
sub3ec-.=/C=de/ST==ppp/L=Bibberberg/0=Inte^^ sprechender 
Elsfanteri/CN=Benjaniin El\xFCmchen " 

issuer^ /C=de/ST=demo/0«IP-Web/OU=deino/CN-IP-Web Demo Patients CA 
BEGIN CERTIFICATE faxiem:s 

ZTz.NMAsGA10ECBMEZGVtbzEPMAOGAlUEChMGSVA-V2ViMQOwCwYDVQOLEwRkZWlv 
^^o''S^n^X^?^^'''^^"^^^2WIgRGVtbyBQYXRpZW50cyBDQTAeFw0wMTAzMTqwM^ 

MRMwEQYDVQQHEwpCaWJi2XJiZXJnMTQwMgYDVQQKEytabnRlcmV2c2V 
aWdlbmcgc3ByZWNoZW5k2XIgRWxlZinFudGVuMRowGAYDVQQDFBFCZW5QYWlDbiBC 
^ K.^e^in£2''^°*^^^'3GSIb3DQEBAQUAA0sAMEgCQQDgnGfa 
n^f.o^'!2^"^"'**P^^"°^^^"/^^®li^^*^3vaf8D0pMhI6iqpq 

^ Sr? F®^'*^=^^^^^^'5^^Q""'^0^^iC^spFL5WVH3QKbAXWHdJJsiOSTti 

24?KF5??nD""^"^^^'^''^°^^^^^^^^^^ 
END CERTIFICATE 



60 [0131] Die wesentlichen Komponenten sind der private Schlussel ("BEGTN/RND RSA PRTVATR KEY") sowie das 
X.509-Zertifikat mit dem oflFentlichen Schlussel ("BEGIN/END CERnRCATE"). Beide Beslandteile sind in der Dar- 
stellung base-64-kodiert, was jedoch nur der Ubertragbarkeit binarer Daten und nicht der Zugriffssicherheit dient. Die 
weiteren Angaben dienen nur der interna Organisation des PKCS-12-Fonnates. 

[0132] Dieses Format entspricht im Wesentlichen auch d^ intemen Darsteilung auf einer Smart-Card. . 
65 [0133] Das Zertifikat, das die Echtheit des SchlQssels durch TVust-Center best^tigt, hat (nach base-64-Dekodierung) 
folgende Stniktur (nach PC.509]). 
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Certificate: 

Date: 

version: 3 (0x2) 

Serial Number: 984 936122 (Ox3ab4eeba» 
Signature Algorithm: mdSWithRSAEncryption 

Slidity''^''^' ST^demo, 0=IP-Web, OU^demo, CN=IP-Web Deno Patients CA 
Not Before: Mar 18 00:00:00 2001 GMT 
Not After : Mar 18 23:58:00 2003 GMT 
Subject: C=de, ST=ppp, L^Bibberberg, 

0-Interessenvereinigung sprechender Elefanten, 
CN=Ben3amin Bl\xFCmchen 
Subject Public Key Info: 

Public Key Algorithm: rsaEncryption 
RSA Public Key: (512 bit) 
Modulus (512 bit) : 

00:e0:9c:67:da:67:le:98:36:da:cl:9f :68:ac•95• 
62:f4:12:96:8d:6d:23:bb:50:13:3e:a4:13:54;a0• 
6a:a7:33:f6:15:15:ed:62:B<:b2:81:bd:a7:fc-0f- 

4a:4c:84:Be:a2:aa:9a:9f:6e:c6:d3:5c:f0-cf -f3• 
bc:^3:b0:17:55 ■^.:>c.ru.cf .f3. 

Exponent: 65537 (0x10001) 
Signature Algorithm: mdSWithRSAEncryption 

Pfl nrZ°^^^=^^=95^^^^^b^b4^58:79:fc:62:8c:05:b0: 
41:2f:6a:0e:b4:27:30:9d:37:6a:20:9d:b2:91:4be5-65-47. 
f^^°^OK^^c^'^^'^ = "''^^2:6c:8c:e4:93:b6:3f:f9 a5;4a 
H7'^^'^^ = ^^^l=^^^2:38:dl:3d:lf:9d:5f:e8:3c:d7:a0:50 db^ 
d7:56:4e:8e:25:37:63:90:e4:6e:9e:da:25:66:de:71:89;ed: 
f e: 3a :ab:af:bl:06:ac:2f:4e:d9: 36:94 :db:8d:4a:16:c3:ff^ 



- "Subject" ist dabei der Name der zu identifizierenden Person 35 

- "issuer" das Tnist-Center, das dieEchtheit bestatigt (vgi. Anspnjch 10a). 

- Validity (Gultigkeitsdatum) und Seriennummer sovvde Version und Algorithmen sind weitere Qrganisadonsbe- 
standteile nach X.509 

- Der offenUiche Schiussel ("RSA public Key") ist wesentlicher Bestandteil des Zertifikats 

- Die Signatur (eingeleitet mit der Angabe des Algorithmus), die die Echtheit des Schliissels bestatigt, schlieBt das 40 
Zertifikat ab. 

[0134] Der private Schiussel ist in einem passwortgeschulzten "Key Bag" untergebracht, d. h. zusatzlich zur base-64- 
Dekodiening ist noch eine Entschliisselung mit deni Pass wort erforderiich. 

[0135] Erst nach Offnen des "Key Bag" durch Passworteingabe (oder Fingerabdruck) eroflfnet sich die interne Struktur 45 
des privaten RSA-Schliissels, wie er zur Verwendung erforderiich ist: 



50 



55 



60 
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10 



15 



20 



25 



30 



35 



40 



Enrer PEM pass phrase: 
Private-Key: {512 bit) 
modulus : 

00:eO:9c:67:da:67:le:98:36:da:cl:9f :68:ac:95 
62:f4:12:96:8d: 6d : 23 :bb : 50 : 13 : 3e :a4 : 13 : 54 : aO 
'«^'^^-^^*^^-®^*^2:84:b2:81:bd:a7:fc:0f 

bc;93;bo;?7;l5^"'='^^''^'^^"'^^^ 

publicExponsnt: 65537 (0x10001) 
privateExponent : 

00:ae:e8:bd: 6a: f3:60: 7c :d2: 42 :ba: 03:04 -05-59 
73:ac:73:89:2f :ea:ec: 37:62 : 2d: Oa :5b: c4ifd!e2 
oo'So'-^Z'"'^'^-^^=^2'^^*3^'Sl-93:4d:89:82:37 

23:28:ib:7c:9f :b6:8e:2a:eb:49:e3:b5:fl:cl: -8 
eb:68:be:b4 :21 
primal : 

n?="'°M^ = ":3d:a3:95:lf :9b:ee:8b:83:b2:57: 

03:2e:d8:3c:35:cb:6c:50:00:le:57:a7:la:37:f4: 
u£ : 5d : c9 

prime2 : 

O0:ea:a7:5b:lc:d3:a0:73:cc:3a:63:ca:33:73:e2: 
f3:cd:e6:4b:3d: 5b : 3c : f 6 : bl : 37 : 37 : 98 : 4e : 34 : 3d: 
c2 : 4 3 : 2d 
exponent 1 : 

00:d2:3b:c2:a5:34:cb:fa:ee:02:97:57:a5'26-c5- 
^|j^a:43:75:31:89:04:a5:62:64:a5:e9:lc:ea:72i 

exponent2 : 

2f:06:a7:ld:d9:d3:98:21:5f :ba: 4b: f 5: 8f:cd:f 5: 
|^:^^ = t)2:d0:73:0e:7e:a9:f9:54:ec:f3:0f :49:29: 

coefficient : 

'?^''^^'°^ = 2^ = 23:d4:le:9c:S8:b4:eb:ll:38: 
^^:^J=32:fe:21:a7:6e:07:21:c9:4b:34:57:ll:43: 



[01361 Fur Schliissel, die auf Smart-Cards abgelegt sind, ist diese Struktur des pri vaten Schlussels von auBen nicht zu- 
ganglich (auch nicht nach Freigabe). AUe zu verschlusselnden Daten mussen in die Smart-Card ubertragen weiden» wcr- 
den dort (nach Freigabe) verschlusselt und wieder aus der Smart-Card ausgelesen. 

3.4.2 Authentifizierungs- Applet 
[0137] Das Authentifizienings- Applet ubemimmt folgende Funktionen: 

45 - Erstellen eines zufallig generierten Session Keys (Anspruch 4 und 11) 

- Ermitteln der aktueilen Systemzeit (fiir Anspruch 4) 

- Ermitteln der Identitat von Arzt und Patient (Anspruch 1 - z. B. "Distinguished Names" nach X500 odcr spezielle 
Arzt-/Padentenindices) 

- Abfragen der Z^ustimmung von Arzt und Patient (Anspruch 1) 

50 - bei Erteilung der Zustimmung: Verschlusselung des Session Keys mit dem jeweiligen privaten Schlussel von 

Arzt und Patient (Anspruch 5 und 6 sowie 12) 

- Zusammenfugen der Komponenten zu einem Session-Request (nach Anspruch 3 ff) 

- Signieren des Session-Request mit dem (unverschlusselten) Session-Key (Anspruch 13) 

55 [0138] Erweiterung: 

Wenn der https-Clienf-Schliissel im Session-Request ubertragen werden solL so muB das Applet diesen vom Browser ab- 
rufen (Anspruch 14 ff, insbesondere 17) 
[0139] Erweiterung: 

Gegebenenfalls werden noch weitere Informationen zur Spezifikation des Kontextes, wie in Anspruch 1 angefuhrt, an- 
60 gegehen 

[0140] Erweiterung: 

Das X.509-Zerdfikat einer an der Authentifizierung beteiligten Person (oder mehrerer Personen), ggf. auch zugehorige 
Zertifizierungsketten, konnen ebenfalls im Antrag mit aufgenommen werden (Anspruch 20). In diesem Fall braucht beim 
Zugriffskonuxjllsystem nur das entsprechende Wurzelzertifikat vorgehallen werden (vgl. Anspruch 19). Damit wird die 
65 Verantwortung, die Berechtigung einer Person, das System generell zu benutzen, zu priifen, von der ZugriffspriifsteUe an 
das Trust-Center abgegeben. 
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3.4.3 Session-Request 

[0141] Der ersteUte Session-Request (s. Anspruch 3 S) hat im Beispiel folgende Struktur (ohne X.509-Zerlififcate nach 
Anspruch 20): 



x-+_0-^-0.0-^- 0.0.0 - session ID 254 bit random 
U.0.1 — Session time Stc 



-0.1- 



-0.2-+- 0.2,0 
0.2,1 
+~ 0.2.2 
+- 0.2.3 



-0.3-+- 0.3.0 
0.3,1 
0.3.2 
+- 0.3.3 



+-0. 4-+- 



0.4 .0 
0.4.1 



:amp 

encrypted Session key (DESede x dccPK 

Docviors Data: 
Subject DN 
Issuer ON 
Serial Number 
Fingerprint 

Patients Data: 
Subject DN 
Issuer DN 
Serial Number 
Fingerprint 

SessionlDblock signed (docPK) 
SessionlDblock signed (patPK) 



X patPK) 



-1 



Bag Seal: MD5 of 0 encrypted with session Key 



10 



15 



20 



25 



[0142] Diese Struktur kann z. B. in ASN. 1 (siehe [X.680]) dargesteUt werden, in Base 64 kodiert und dann als Query 30 
an eine URL angefugt und so via http(s) an das Zugriffskontrollsystem ubertragen werden. 

3.4.4 Authentitatsprufung durch das ZugrifTskontrollsystem 
[0143] Das Zugriffskontrollsystem dekodiert die query: 35 



40 



45 
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raw DER-Structure as Hex-D\mp: 



00 01 02 03 04 05 06 07 



00000000 

00000010 

00000020 

00000030 

00000040 

00000050 

00000060 

00000070 

00000080 

00000090 

OOOOOOAO 

OOOOOOBO 

OOOOOOCO 

OOOOOODO 

OOOOOOEC 

OOOOOOFO 

00000100 

00000110 

00000120 

00000130 

00000140 

00000150 

00000160 

00000170 

00000180 

00000120 

OOOOCIAO 

OOOOOIBO 

OOOOOICO 

OOOOOIDO 

OOOOOIEO 

OOOOOIFO 

00000200 

00000210 

00000220 

00000230 

0OC00240 

00000250 

00000260 



30 82 
30 97 
70 E3 
30 31 
30 04 
81 BB 
3D 48 
97 FA 
AB AD 
6E 20 
6D 65 
73 20 
73 65 
37 43 
4 4 6F 
6D 6F 
65 6D 
5E 9A 
30 81 
20 42 
72 65 
67 20 
65 66 
62 65 
15 38 
2C 50 
64 65 
3D 64 
04 10 
E5 02 
32 12 
A6 89 
5F F4 
A4 4C 
A4 70 
31 91 
97 94 
EF 26 
B8 36 



02 67 
3C 14 
5F AC 
30 34 
4 0 02 
AO 69 
34 BA 
25 BB 
39 30 
4A 6F 
69 6E 
4A 56 
6E 2C 
4E 3D 

63 74 
2C 4F 
dF 2C 
5F 89 
AF 13 
6C 3F 
73 73 
73 70 
61 6E 
72 67 
43 4E 
61 74 
6D 6F 
65 6D 

64 57 
30 81 
28 3C 
3F 4 4 
85 5E 
6D 07 
5D 04 
57 Dl 
6A 2C 
EE AD 
50 48 



30 82 
20 F2 
D< 35 
30 32 
F2 4 3 
6E DC 
25 EB 
50 41 
81 9A 

68 6E 

73 63 
58 20 
53 54 
49 50 
6F 72 
3D 4 9 
43 3D 
C9 CO 
5B 43 
6D 63 
65 6E 
72 65 

74 65 
2C 55 
3D 49 

69 65 
2C 4F 
6F 2C 
A6 FA 
84 04 
OA 4F 
98 75 
7B F8 
60 55 
6r 7E 
39 94 
51 E3 
87 4D 
41 BA 



02 51 
OB 12 
BA 67 
31 31 
E7 9F 
5D OB 
2D F3 
5F 4 4 
13 47 
73 65 
68 61 
40 3D 
3D 62 
2D 57 
73 20 
50 2D 
64 65 
AE 01 
4E 3D 
68 65 

76 65 
63 68 
6E 2C 
54 3D 
50 2D 
6E 74 
3D 4 9 
43 3D 

06 8C 
40 06 
E8 EE 
CI EF - 
OD A3 ■ 
BA 04 • 
AD 9C - 

07 B6 - 
59 C5 - 

77 8A - 
90 F9 - 



66 
41 



08 09 OA OB OC OD OE OF 0123456789ABCDEF 

69 AD 0. .gO. ,Q07. . .1. 

B3 34 0.< ).Mlh.4 

32 30 p._. .5.g. .N. . .20 

32 30 010402115953-^020 

73 E5 0.(3. .C. , .}.;L.s. 

03 20 . . .in. 1 . .OC.W:$., 
5F CB =H4.%.-.n. .%. 
96 5C . ]A_D. . .Xu*.\ 
61 6E . . 90. . .GCN=Johan 

4 7 65 n Johnseder, 0==Ge 
78 69 meinschaftspraxi 
61 75 s JVX,L=Anderhau 
65 13 sen,ST=bbb,C=de. 
6F 20 7CN=IP-Web Deiro 

64 65 Doctors CA, OU=dG 
3D 64 mo,0=IP-Web,ST=d 
04 10 emo, C=de. . : . .5. . 

33 Jw. . . J3 

69 6E 0. . . [CN=Benjarain 

7 4 65 Bl?mchen, C-Inte 

7 5 6E ressenvereinigun 

4 5 6C g sprechender El 

65 72 ef anten, L=Bibber 
64 65 berg, ST=ppp,C«de 
6D 6F .8CN-IP-Web Deitio 
55 3D Patients CA, OU= 
53 54 demo,0==IP-Web, ST 
EE BA =demo, C»de 

IB 56 . .dW <. V 

FC 60 - . 0 . . . @ . . % * 

IB B5 2. (<.0. . , $ , . 

5F D2 . . ?D.u. . . f . 

8D 6A t.\;. . j 

55 4 0 .L.-n.lU. .ei. . .Loe 

EO C7 .p] .0-. .w >. . 

68 B9 1 . . .9 02. .h. 

2A 51 ..j,Q. Y.L.N!. . *Q 

ID B9 . .Mw.k 

. 6PHA. . . .U. 



30 37 04 
AC 7D BO 
B4 CF 4E 
35 39 35 
AE 7D E5 
EE 55 45 
6E C9 Al 
EE 06 18 
43 4E 3D 

64 65 72 
74 73 
6E 64 

• 62 62 2C 
■ 65 62 20 

• 43 41 2C 
57 65 62 
02 04 3A 
2E 4A 77 
42 65 6E 
6E 2C 4F 

72 65 59 

65 6E 64 
4C 3D 42 
70 70 70 
57 65 62 

73 20 43 
50 2D 57 
64 65 02 
OE A9 01 
A7 25 15 
02 24 AF 
EE 66 82 
E6 74 03 
40 6C 12 
77 F7 08 
08 AC 30 
4C 82 4E 
6B 04 10 
BD 55 83 



20 17 82 
4D 31 68 
OF 18 13 
33 2B 30 
3B 4C DF 
2E 57 24 
25 B5 91 
58 75 2A 
4A 6F 68 
20 4F 3D 
70 72 61 
65 72 68 

43 3D 64 

44 65 6D 
4F 55 3D 
2C 53 54 
B4 EC 35 
A7 B2 02 
6A 61 6D 
3D 4 9 6E 
6E 69 67 
65 72 20 
69 62 62 
2C 43 3D 

20 44 65 
41 2C 4F 
65 62 2C 
04 3A B4 
E3 Dl 3C 
ED 96 04 
2B 7E E3 
FC 2B 16 
5C 3B 9A 
FA E8 4C 
98 A2 3E 
7A 17 15 

21 FE A7 
IF BO OB 



45 



[0144] Daraus ergibt sich die ASN.l-Struktur, die die Xomponenten des Session-Requests offenlegt (vgl. ASN.l- 
Struktur wie oben angegeben): 



50 



55 



60 



65 
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ASNl-Strocture of Reouest: 



0 

4 ; 
8; 
10; 
44 : 
65: 
131: 
134 : 



1-0 
I 
2 
3 
3 
2 
2 
3 



hl-4 1= 615 cons: 
hl=4 1= 593 cons: 
hl=2 1= 55 cons: 
32 prim: 
19 prim: 
64 prim: 
hl=3 1= 154 cons: 
hl=2 1= 71 prim: 



SEQUENCE 
SEQUENCE 
SEQUENCE 
OCTET STRING 
GENERALIZEDTIME 
OCTET STRING 
SEQUENCE 

^„ , ^ - ^ PRINTABLESTRING : 

CN=Jcnann Johnseder, 

0=Gemeinschaftspraxis JVX, L=Anderhausen, ST-bbb,C=de 



hl=2 1= 
hl=2 1= 
hI-2 1= 



20010402115 953+0200 



207:d=»3 hl-2 1= 55 prim: 



PRINTA3LESTRING 

Doctors CA,OU«demo,0-IP-Web,ST=denio,C=de 
INTEGER :3AB4EC35 
OCTET STRING 
SEQUENCE 
PRINTABLESTRING : 



264:d=3 hl=2 1= 4 prim: 
270:d=3 hl=2 1= 16 prim: 
288:d=2 hl-3 1« 175 cons: 
291:d-3 hl=2 1= 91 prim: 
CN=Benjamin Bl?mchen, 
0=lnteressenvereinigung sprechender Elefanten, 
L=Bibberberg, ST=ppp, c=de 
384:d-3 hl=2 1= 56 prim: PRINTABLESTRING 

CN-IP-Web Demo Patients CA, OU=demo, 0=IP-Web, ST-demo, C=de 



442: 
448: 
466: 
469: 
535: 
601: 



d= 
d= 
d= 
d 

d= 
d 



hl=2 1= 
hl=2 1= 



4 prim: 
16 prim: 



hl=3 1= 132 cons 
hl«=2 1= 64 prim 



hl=2 1- 
hl=2 1= 



64 prim: 
16 prim: 



INTEGER 
OCTET STRING 
SEQUENCE 
OCTET STRING 
OCTET STRING 
OCTET STRING 



: 3AB4EEBA 



10 



15 



20 



25 



30 

[0145] Es liegen nun die Informationen vor, um die tJberpriifung der Authentizitat vorzunehmen: 

- aus den Identitatsinformationen von Arzt und Patient sowie deren Zertifiziereni werden die entsprechenden Zer- 
tifikate ermittelt 

- tiber Seriennummer und Fingerprint der Zertifikate wird ein erster Echtheitstesl voigenomnten (Anspruch 18) 35 

- Die Zertifikate enthalten den jeweiligen ofifentlichen Schliissel 

- der verschliisselt vorliegende Session Key wird mit den beiden ofifentlichen Schlusseln von Arzt und Padent ent- 
schltisselt (Anspruch 12): 

Dann und nur dann wenn sowohl Arzt als auch Patient mit dem richtigen privaten Schliissel gearbeitet haben, laBt 
sich so der ursprungliche Session Key wiederherstellen 40 

- Es wird der Hash- Wen des Session-Requests gebildet und rait dem wiederhergestellten Session Key verschlus- 
selt. Wenn das Ergebnis mit dem ubennittelten Wert ("Bag Seal") identisch ist, dient das als Beweis fiir cine kor- 
rekte Authentifizierung (Anspruch 13) 

[0146] Der so wiederhergestellte Session Key kann bei Bedarf weiter verwendet werden, um die weitere Kommunika- 45 
tion zu verschlusseln, so daB nur die berechtigten Parteien daran teilnehmen konnen (Anspruch 15). 
[01471 Erweiterung: 

Das ZugriffskontroUsystem kann den ssl-Schlussel des Clients aus der Netwerksoftware abrufen, wenn diese Informa- 
tion nicht Bestandteil des Session-Requests ist. Damit entfallt clientseitig die Notwendigkeit, daB das Applet auf den 
https- Schliissel zugreifen muB. Dies wiedenim vereinfacht die Verwendung von Standardbrowsem auf Clientseite. 50 

3.4.5 Freigabeserver 

[0148] Der entschlusselte Session-Key, die ssl-Idendtat des PC in der Arztpraxis und die anderen Informationen des 
Session-Requests werden an den Freigabeserver (nach Anspruch 23) ubermittelt. Hierzu kann z. B. das Zugriffskontroll- 55 
system eine https- Verbindung zu diesem autbauen (vgl. Anspruch 24, 26, 27). Der Freigabeserver speichert die Informa- 
tionen, um sie filr den Fall eines Datenabrufs auswerten zu kOnnen. 

[0149] Daraufhin ubermittelt das ZugriffskontroUsystem eine Erfolgsmeldung an den Browser beim Arzt, die sinn voll- 
erweise einen Hyperlink auf den Freigabeserver (bzw. je einen Link auf jeden Server, wenn Datenbestande an verschie- 
denen Stellen vorliegen) enthSlt. AuBerdem konnen die T.inks (gemaB Anspruch 28 und 29) Query-\^riablen entlialten, 60 
die zur weiteren Spezifikation der verlangten Daten dienen (z. B. Namen des PaUenten, um Verwechslungen bei kurz 
aufeinanderfolgenden Abfragen zu vermeiden). 

[0150] Durch Aktivieren der Links im Browser (Anspruch 41 ff) sendet das Arztsystem nun einen http(s)-Request an 
den Freigabeserver. Dieser ruft die gewuoschten Daten aus der Datenbank ab und erhalt von dieser (ggf auch vorher) die 
for den Zugrifif erforderlichen Voraussetzungen (Anspruch 30 IT). Diese Voraussetzungen vergleicht er mit den gespei- 65 
cherten Daten aus dem vorher ubermittelten Session-Request (Anspnich 30). 

[0151] Des weiteren ermiUelt der Freigabeserver die ssl-Identitat des Arzt-PC und vergleicht sie mit der vom Zugrififs- 
konUoUsystem ubennittelten (Anspruch 35, 36). Damit wird v^bindert, daB ein unbefugter Benutzer mit einw aufge^ 
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zeichneten Zugriffssequenz, die er zwar nicht analysieren, aber 1 : 1 wiedergeben kann, Datenzugrilf erhalt ("replay-at- 
lack"). 

[0152] Wenn alle Priifungen erfolgreich sind, ubertragt der Freigabeserver die erbetenen Daten als http(s)-Response an 
den Arzt-PC. Dieser Response kann weitere Hyperlinks zu anderen Daten auf dem gleichen oder einem anderen System 
enthalten (Anspruch 41 ff). Sofem fur einen Abruf bestimmle Inhalte einer URL-query erfordcrlicb sind, werden diese 
im Response weitergereicht C'state-Management" im http-ProtokolL vgl. auch Anspruch 28 und 29). 

3.5 Erganzungen und Erweiterungen 

[0153] Wichuge Varialionen der Erfindung, die hier im Ausfuhrungsbeispiel nicht oder nur andeutungsweise erfaBt 
sind, werden im Folgenden noch angeftihrt. 

3.5.1 Komplexe Verschlusselung in der Dateniibertragung 

[0154] Im beschriebenen Beispiel erfolgt die Ubertragung zwischen freigebender Stelle uber https, also verschliisselt 
mil dem ssl-Client-Schlussel des Arzt-PC. Dieser Schlussel ist iiblicherweise auf dem Rechner in einer Datei abgelegt 
und ist damit unbefugten Zugriffen z. B. bei der Rechneradministration ausgesetzt C*man-at-the-end-attack"). Dieser 
Schlussel bietet also bei weitem nicht die Sicherheit wie die Smart-Card-basierten SchlUssel zur personlichen Authenti- 
fizierung. 

[0155] Alternative Schlussel, die diesen Mangel beheben konnen, sind in Anspruch 37/38 beschrieben. Insbesondere 
der Session Key kame hierfur in Frage. Die meisten dieser Losungen haben jedoch den Nachteil, daB clieniseitig keine 
Standardbrowser mehr verwendet werden konnen. 

3.5^ Schreibender Datenzugriff 

[0156] Die bisherigen Beschreibungen des Ausfuhrungsbeispiels beziehen sich teilweise implizil auf lesenden ZugrilT. 
[0157] Die Ablaufc fur schrcibcndcn Zugriff (Daten anlcgcn, andcm, loschcn, Rcchtc andcm) sind wcitgchcnd idcn- 
tisch. Lediglich der Freigabeserver und die Konmiunikation mit der Datenbank muB entsprechend angepaBt werden. Als 
KommunikationsprotokoU mit dem Client kanii weiterhin http(s) verwendet werden, das durch Formulare und POST-Re- 
quests eine Dateneingabe ermoglicht. 

3.5.3 Verzeichnisdienste fur Zertifikate 

[0158] Das beschriebene Ausfuhrungsbeispiel geht nicht darauf ein, woher die Zertifikate kommen, die fiir die Authen- 
titatsuberpriifung eingesetzt werden. Neben der tJbermitdung mit dem Session Request nach Anspruch 20 sind die Va- 
riadonen in Anspruch 21 und 22 dargelegt. 

[0159] Eine sinnvoUe Moglichkeit ware etwa, wenn die Ausgabe der Smart-Cards von einem TYust-Cent^ erfolgt, das 
nicht nur die Identitat des Inhabers, sondem auch weitergehende Voraussetzungen zur Teilnahme am System (z. B. bei 
einem Arzt die fachliche Zulassung) priift und festhalt. Diese Informationen konnen dann - zusanMnen mit dem Zertifikat 
- von dicsem Thist-Center uber IX) AP (ggf. uber eine gesicherte Verbindung) dem Zugriffskontrollsystem ubermittelt 

werden. . . u / r> 

[0160] Bei einem Ausbau des Systems konnen mehrere unabhangige Stellen diese Zertifizierung ubOTiehmen (z. B. 
Krankenkassenfilialen fiir Patienten). In diesem FaU empfiehlt sich ein mehrstufiges Zertifzierungsverfahren, wie es in 
[X.509] vorgesehen und in Anq>ruch 18 fF angefuhrt ist. 

3-5.4 Verzeichnis der verfiigbarwi Daten 

[0161] Die beschriebene Realisierung geht davon aus, daB letztlich erst das datenhaltende System detaillierte Informa- 
tic«ien besitzt, welche Daten zu einem spezifischen Kontext zur Verfugung stehen. 

[0162] Diese Information kann aber auch anders iiber die einzelnen Systemkomponenten (ZugriffskontroUe, Freigabe, 
mehrere datenhaltende Stellen, dedizierte Verzeichnisse) verteilt werden. Auch eine Kombination mit anderen Dalenbe- 
standen (Verzeichnisdienst nach vorgehendem Abschnitt, ZugrifiFskontrolliste) ist denkbar. 

[0163] Die detaillierten Variationsmoglichkeiten des Datenbankdesigns ergeben sich aus praktischen und sicherheits- 
potitischen Erwagungen und gehen uber den in diesem Patent beanspruchbaren Rahmen hinaus. 

3.5.5 Iterative Zustimmung zur Datenfireigabe 

[0164] In der Zeichnung zum Gesamtsystem ist ein "Selection Key" angedeutet, der verwendet wird, wenn der Patient 
explizite Zustimmung zur Offenlegung einer beschrankten Teilauswahl aus alien verfiigbaren Informationen erteilen 
soli. Tn den weiteren Erlauterungen wurde aus Griinden der UbersichtHchkeit hierauf nicht weiter eingegangen. 
[01651 Hierbei handelt es sich um kontextspezifische Informationen (nach Anspruch 1), die durch mehrere Anforde- 
rungszyklen (nach Anspruch 41) ermittelt werden. 

[0166] Der Selection Key ubemimmt dabei die Rolle des Session Key; es wird gleichsam durch Iteration nach An- 
spruch 41 ein neuer Kontext nach Anspruch 1 eroffn^. 

3.5.6 Vertietung von Personen 
[0167] Anspruch 45 erwahnt verschiedene V«rtretungskonstellationen. Beispiele hierfur konnen sein: 
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- nicht ein Arzl selber, sondem ein Assistent rufl Daten ab 

- Palienten werden von Erziehungsberechligten oder einem Vbrmund vertreten 

- Ein "Notzugang" ermoglicht den Zugrifif auf Dateri von Patienten ohne BewuBtsein 

- ZugrifFsrechte werden nicht einer Person, sondem einer Organisation gewahrt 

- Zugrilfsschlussel konnen in einer Software, z. B. der Praxissoftware des Arztes, hinterlegt sein 

- Applikationen in anderem als dem hier beispielhaft dargestellten Kontext konnen andere Vertretungsmoglichkei- 
ten beinhalten 

10168J Welche VertretungsnndgLichkeiten zugelassen sind ist eine Fragc der Sicherheitspolitik. 

3.5.7 Fesllegung einer Sicherheitspolitik 



iU 



[0169] Viele KnLscheidungen uber die Tmplementierung konnen nicht nach technischen Erwagungen auf der Suche 
nach einer "bestmoglichen Sicherheit" getrofifen werden, sondem entstehen durch Abwagung zwischen Sicherheitstech- 
nik, rechtlichen Anforderungen, Kompatibiiitat mil bestehenden Systemen oder Bedienbarkeit. Selbst subjektive \fer- 15 
trauens-"Gefuhle" mussen hier mit einbezogen werden. Diese Erwagungen entziehen sich natuigemaB der technischen 
Natur eines Patentes, weshalb in dieser Beschreibung derartige Entscheidungen und Varianten regelinaBig ofFen gelassen 
werden. 

[0170] Aufbauend auf dem hier beschriebenen Grundgeriist konnen Anpassungen an eine voigegebene Sicherheitspo- 
litik - bei gegebenen Anforderungen - durch einen geubten Fachmann vorgenommen werden. 20 

■•^^ ■ ■ • . 

Patentanspriiche 

1 . Verfahren zur Zugriffsteuerung auf eiektronisch gespeicherte Daten in verteiiten heterogenen Umgebuhgen, ge- 
kennzeichnet dadurch, dafi 25 
die Freigabe des Datenzugrins durch iiiehrere Personen erfolgl 

cine drittc StcUc zur Frcigabcpriifung zwischen Datcnabrufstcllc und DatcnspcichcrstcUc cingcschaltct ist 

fur die Uberpriifung der Authentizitat der Freigabe erteilenden Personen kryptographische \ferfahren mit ofFentli- 

chen und privaten Schliisseln verwendet werden 

die Kontextsituation der Personen im Rahmen der Datenanforderung mit in den Umfang der erteilten Freigabe ein- 30 
flieBen kann. 

2. Verfahren nach Anspruch 1, gekennzeichnet dadurch, daB 

fiir die Dateniibertragung geeignete NetzwerkprotokoUe verwendet werden konnen, 

fur die Datenubertragung die Internet-ProtokoU-Familie (insbesondere IP, TCP, UDP) verwendet werden konnen, 

flir die Datenubertragung das Internet verwendet werden kann. 35 

3. Verfahren nach Anspruch 1, gekennzeichnet dadurch, daB fur jeden V^rgang, bei dem eine Freigabe angefordert 
wird 

ein spezielles digitales Freigabeobjekt ("Authentifizierungsantrag") zur Kommunikation der beteiligten Systeme 
untereinander erstelU wird 

das Freigabeobjekt ein eindeutiges Merkmal des Authentifizierungsvorganges enthalt 40 
das Freigabeobjekt weitere Daten uber den Authentifizierungskontext enthalten kann 

4. Verfahren nach Anspruch 3, gekennzeichnet dadurch, daB 

das Freigabeobjekt einen zufallig generierten oder anderweitig als eindeutig geltenden digitaien Schliissel zur Iden- 
tifikation des Authentifizierungsvorgangs enthalten kann 

das Freigabeobjekt einen Zeitstempel des Authentifizierungsantrages enthalten kann 45 
das Freigabeobjekt Angaben uber den zeitlichen Geltungsbereich der Authentifiziening enthalten kann 

5. Verfahren nach Anspruch 1 , gekennzeichnet dadurch, daB die am Authentifizierungskontext beteiligten Personen 
durch asymmetrische ctigitale Schliisselpaare identifziert sind 

6. Verfahren nach Anspruch 5, gekennzeichnet dadurch, daB eines der folgenden Verfahren fur die asymmetrischen 
digitaien Schliissel verwendet wird: 50 
RSA - 

DSA 

elliptische Funktionen 

7. Verfahren nach Anspruch 5, gekennzeichnet dadurch, daB der private Schliissel einer an der Authentifiziening 
beteiligten Person auf einer physikalisch eigenstandigen Einheit gehalten wird, die 55 
von der Person mitgefUhrt werden kann 

vom System, das an der DatenabrufsteUe zur Anforderung der Datenfreigabe verwendet wird, getrennt werden kann 
mit unterschiedlichen Systemen zur Anforderung der Datenfreigabe verwendet werden kann 

die erforderlichen Verschliisselungsoperationen selbst vomehmen kann, so daB der private Schltissel der Fterson 
nicht an das System zur Anforderung der Datenfreigabe iihertragen werden muB 60 

8. Verfahren nach Anspruch 7, gekennzeichnet dadurch, daB diese eigenstandige Einheit eine handelsubliche 
Smart-Card (integrierter Schaltkreis, eingebaut in ein KunststofFgehause im Scheckkartenformat) mit Kryptopro- 

zessor ist 

9. Verfahren nach Anspruch 5 bis 8, gekennzeichnet dadurch, daB der private Schlussel duich ein biometrisches 
Merkmal vor unbefugter Verwendung geschutzt ist . 65 

10. Verfahren nach Anspruch 9, gekennzeichnet dadurch, daB als biometrisches Merkmal eines oder mehrere der 
Folgenden verwendet werden konnen: 

individueUer Fingerabdruck 
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individuelle Iris-Musterung 
individuelle GesichlszUge 
individuelle Sprache 
genetische Muster 

5 Muster aus der Gen-Exprimierung, insbesondere RSA und Proieine 

11. Verfahren nach Anspruch 1 bis 10, gekennzeichnet dadurch, daB fur die Identifikation des Authentifizierungs- 

kontextes eine eindeutige binare Sequenz als "Session Key" verwendet wird 

12. Verfahren nach Anspruch 11, gekennzeichnet dadurch, daB der Session Key mit privaten Schliisseln von am 
Kontext beteiligten Personen verschlusselt wird 

10 13. Verfahren nach Anspruch 3, 11 und 121 gekennzeichnet dadurch, daB die Integritat des Authentifizierungsan- 

trages dadurch gewahrleisiet wird, daB der gesamte Antrag oder Teile davon mit dem Session Key oder einer davon 
abgeleiteten binaren Sequenz digital signiert wird 

14. Verfahren nach alien bisher genannten Anspriichen, gekennzjeichnet dadurch, daB das System, das zur Anfor- 
derung der Datenfreigabe verwendet wird, Bestandteil des Authentifizierungskontextes ist 
15 15. Verfahren nach Anspruch 14, gekennzeichnet dadurch, daB 

das anfordemde System gegeniiber dem prufenden System durch ein unabhangiges asymmetrisches Schliisselpaar 
identifiziert werden kann 

die Kommunikation zwischen anfordemdem System und priifendem System verschlusselt erfolgen kann 

16. Verfahren nach Anspruch 15, gekennzeichnet dadurch, daB die Kommunikation zwischen anfordemdem Sy- 
20 stem und priifendem System iiber eine Variante des Protokolls ssl oder tls ("secure Socket Layer") erfolgen kann 

17. Verfahren nach Anspmch 16, gekennzeichnet dadurch, daB zur Authentifizierung des (lerates gegeniiber der 
prufenden Stelle und zur Verschliissclung der Dateniibertragung das Protokoll https ("http over ssl") verwendet wird 

18. Verfahren nach den bisher genannten Anspriichen, gekennzeichnet dadurch, daB die Uberpriifung der Gultig- 
keit von Autbentizitatsbehauptungen anhand einer dieser Mdglichkeiten erfolgt: 

25 eines bei der priifenden Stelle hinterlegten dffentlichen Schliissels als Gegenstiick zum privaten Schliissel des zu au* 

Ihentilizierenden Akteurs 

der clcktronischcn Bcschcinigung cincr vcrtraucnswiirdigcn Instanz ("TVust Center"), dcrcn offcntlichcr Schliissel 
bei der priifenden Stelle vorliegt 

der elektronischen Bescheinigung einer vertrauenswiirdigen Instanz ("Trust Center"), deren Authentizitat von einer 
30 Kette aus Authentizitatsbescheinigungen besteht, wobei am Anfang der Kette eine Instanz stehl, deren dfifentlicher 

Schliissel bei der priifenden Stelle vorliegt 

19. Verfahren nach Anspruch 18, gekennzeichnet dadurch daB fiir Authentizitatspriifiing die \ferfahren verwendet 
werden, wie sie in ISO X.509 feslgelegt sind 

20. Verfahren nach Anspruch 18 und 19, gekennzeichnet dadurch, daB zur Authentifikation erforderliche ZusatzJn* 
35 formationen (z. B. X.509-Zertifikate, Zertifikatsketten oder veigleicbbare Daten) zusammen mit dem Freigabean- 

trag iibermittelt w^den konnen 

21. Verfahren nach Anspruch 18, 19 und 20, gekennzeichnet dadurch, daB die zur Authentizitatspriifung erfordo'- 
lichen dffentlichen Schliissel sich in einer Datenbank an einer der folgenden Standorte befinden: 

der prufenden Stelle selbst 
40 innerhalb der unmittelbaren, kontrollierbaren Sicherheitssphare der priifenden Stelle 

einer offentlich verfiigbaren Stelle, zu der von der priifenden Stelle aus eine unverfalschbare Daten verbindung be- 
steht 

22. Verfahren nach Anspruch 21, gekennzeichnet dadurch, daB die Ubertragung zwischen der prufenden Stelle und 
d^ Datenbank durch eines der folgenden standardisierten Protokolle erfolgt 

45 rrU-T-EmpfrfilungX500ff. 

Ligbtwighted Directory Access Protocol (LDAP) 

23. Verfahren nach einem der bisher genannten Anspruchen, gekennzeichnet dadurch, daB 

die Priifung der Authentizitat der Freigabe erteilenden Akteure durch eine andere Stelle erfolgen kann als dei; die 
die Daten frei gibt 

50 die Freigabe der Daten durch eine andere Stelle erfolgen kann als der, die die Daten gespeichert hat 

24. Verfahren nach 23, gekennzeichnet dadurch, daB 

die priifende Stelle an die freigebende SteUe einen geeigneten Datensatz ubertragt, der der freigebenden SteUe die 
Evaluation des Kontextes ermoglicht ("push Session Request") 

dieser Datensatz an der freigebenden SteUe ge^)eichert werden kann, bis eine Anforderung von der abrufenden 
55 Stelle erfolgt 

und/oder autgrund des Freigabedatensatzes bereits Daten an die abrufende Stelle gesandt werden konnen 

25. Verfahren nach 23, gekennzeichnet dadurch, daB die &eigebende Stelle von der priifenden Stelle einen geeig- 
neten Datensatz abruft, der der freigebenden Stelle die Evaluation des Kontextes ermoglicht, sobald eine Anforde- 
rung zur Datenfreigabe an sie gerichtet wird ("pull Session Request") 

60 26. Verfahren nach Anspruch 23 bis 25, gekennzeichnet dadurch, daB 

die Kommunikation zwischen freigebender und priifender Stelle mit wechselseitiger kryptographischer Authentifi- 
zierung erfolgen kann 

die Kommunikation zwischen freigebender und datenhaltender Stelle mit wechselseitiger kryptographischer Au- 
thentifizierung erfolgen kann 
65 die Kommunikation zwischen freigebender und priifender Stelle verschltisselt erfolgen kann 

die Kommunikation zwischen freigebender und datenhaltender Stelle verschlusselt erfolgen kann 

27. Verfahren nach Anspruch 26, gekennzeic^et dadurch, daB 

die Konmiunikation der benannten Systeme iiber ssl (oder tls) erfolgt 
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die Kommunikalion der bcnannlcn Syslcinc iibcr hltps erfolgen kann 

28. Verfahren nach Anspruch 23. gckcnnzcichnci dadurch, daB anstatl oder eiganzend zu einer direklen Kommuni- 
kation zwischen frcigebendcr und prii fender Sielle die priifende Stelle ein geeignetes, von der priifenden Stelle si- 
gniertes, kryptographisches Datum ("liekel" oder "lokcn") an die anfordernde Stelle iibennittelt, das die Richtigkeit 
der Aulhentifizierung beweisi und mil deni sich (l:inn die anfordernde Stelle der freigebenden Stelle gegenuber aus- 5 
weisen kann 

29. Verfahren nach Anspruch 28. gckcnn/.eichnei (iaciurch, daB dieses Token iiber gceignele http-state-Manage- 
ment-Technologien iibertragen wird, insbcsonderc 

im Browser der anfordemden Stelle gespeichcric Variahlcninhalle ("Cookies") 

von Requeslzyklus zu Requestzyklus weiicrgcreichic URI.-Query- bzw. HTTP-POST- Variablen-Inhake lo 

30. Verfahren nach bisher genannten Anspriichcn, gckcnnzcichnet dadurch, daB 

die freigebende Stelle fiber eine "Zugriflskoniroilisic" vcrfugl, die angibt, wer unter welchen \braussetzungen Zu- 
griff mit welcher Berechfigung auf welchc Dalen hal 

der Inhalt des Zugriffsantrages, insbesondcrc auch <iie enisprechenden Infortnationen iiber den Zugfififskontext, niit 
den Vorgaben aus der ZugrifTskontrolIisie vcrglichen werdcn und daraus die zugestandenen ZugriflFsrechte abgelei- 15 
tet werden 

31. Verfahren nach Anspruch 30, gekennzcichnci dadurch. daU die freigebende Stelle die ZugriflfskontroUinfonna- 
lionen bei Bedarf von dem datenhalrenden Sysiciii abrufi 

32. Verfahren nach Anspruch 30, gekennzcichnci dailureh. daB <He datenhahcnde Stelle die ZugriflfskontroUinfor- 
mationen direkt mit den erbetenen Daten - noch vor tier Bcrcchiigungspriifung - an die freigebende Stelle iibermit- 20 
telt 

33. Verfahren nach Anspruch 32, gekennzeichnci dadurch. daB 

das datenhaltende System die erbetene Antwon an das freigebende System im HTML-Format ubermitlelt 

die ZugrifFskontrollinformationen als spezifischc. ini Browser nichi slorcndc oder vom Freigabesystem zu entfer- 

nende HTML-Tags ubermittelt werden 25 

34. Verfahren nach Anspruch 32, gekennzeichnei dailureh. daB 

das datenhaltende System die crbctcnc Antwort an das freigebende System im XML-Format ubermittelt 
die ZugrifFskontrollinformationen als eigens definierie XML-Ulcmenle oder - Attribute ubermittelt 

35. Verfahren nach bisher genannten Anspriichen (insbcsonderc 14 bis 17), gekennzeichnet dadurch, daB 

der ZugrifP auf freigegebene Daten nur von dem System aus erfolgen kann. das die Freigabeanforderung erstellt hat 30 
die Aulhentifizierungsinformationen des Zugriff veriangcndcn Systems vom Authentiztat priifenden System an das 
freigebende System mit ubermittelt werden 

diese Authentifizierungsinformationen netzwerkspezifischc Daten (z. B. IP-Adresse, DNS-Namen) enthalten kon- 
nen 

diese Authentifizierungsinformationen Bestandteile oder eindeutige MerkmaJe eines krypiographischen Schlussel- 35 
paares enthalten konnen 

36. Verfahren nach Anspruch 35, gekennzeichnet dadurch daB 

die priifende Stelle an die freigebende Stelle den ssl-Client-Schliissel der anfordemden Stelle ubermitteln kann 
die freigebende Stelle mit der anfordemden Stelle iiber ssl oder tls (ggf. als hltps) kommunizieren kann 

37. Verfahren nach bisher genannten Anspriichen, gekennzeichnet dadurch, daB die Kommunikalion zwischen der 40 
freigebenden Stelle mit der anfordemden Stelle auf Netzwerk- und/oder Datenebene mit (unter anderem) einem 
oder mehreren der folgenden Schliissel verschliisselt und/oder authentifiziert werden kann: 

Session-Key der kontextbezogenen Anforderung 

Schliisselpaar einer oder mehrerer der am Kontext der Anforderung beieiligten Personen 

Schliisselpaar des zur Anforderung verwendeten Systems 45 
Schliisselpaar des freigebenden Systems 

38. Verfahren nach Anspruch 37, gekennzeichnet dadurch, daB anstatl einer direkten ^^rschlusselung auch eines 
der in der Kryptographie bekannten Hybridverfahren verwandt werden kann 

39. Verfahren nach bisher genannten Anspriichen, gekennzeichnet dadurch, daB 

freigebende und datenhaltende Stelle in einer Firewall-Topologie eingebaut sind 50 
hierbei die datenhaltende Stelle im geschiitzten intemen Beieich und die freigebende Stelle in der "DMZ" ("entmi- 
litarisierten Zone") der Firewall liegen kann 

40. Verfahren nach Anspruch 39, gekennzeichnet dadurch, daB die freigebende Stelle als "Application level Proxy" 
auf Schicht 7 des OSI-Referenzmodells realisiert ist 

41. Verfahren nach bisher genannten Anspriichen gekennzeichnet dadurch, daB 55 
die Freigabe der Daten in mehreren Anforderungszyklen erfolgen kann 

die Freigabe anfordemden Personen dabei weitere Kontextinformationen nachliefem konnen 
die Freigabe erteilende Stelle Informationen iiber verfugbare Daten und/oder erforderliche weitere Kontextinforma- 
tionen an die Freigabe anfordernde Stelle senden kann 

durch wiederholle Zyklen der Umfang der freigegehenen Daten erweitert. oder konkretisiert. werden kann 60 

42. Verfahren nach Anspruch 41 gekennzeichnet dadurch, daB 

zur Vermitdung zwischen den Zyklen Hyperlinks, wie sie etwa aus dem WWW bekannt sind, verwendet werden 
konnen 

diese Hyperlinks statisch festgelegt oder dynamisch von den beteiligten Systemen generiert werden konnen 

43. Verfahren nach Anspruch 41 und 42, gekennzeichnet dadurch, daB die Hperlinks in Dokumenten folgender 65 
Stniktur enthalten sein kdnnen: 

Hypertext Markup Language (HTML) 
Extended Markup Language (XML) 
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44. Verfahren nach Anspnich 41 bis 43, gekennzeichnet dadurch, daB zur Ubcrtragung wahrend der Anfordenings- 
zyklen eine Variante des Intemet-ProtokoUs http (insbesondere auch htips) verwendet wird " 

45. Verfahren nach bisher genanntCT Anspriichen, gekennzeichnet dadurch, daB 

an die S telle von naturlichen Personen auch andere juristische Personen treten konnen 
5 Personen auch andere vertreten konnen 

die Rolle von Personen, die im eigenen Namen oder in Vertretung handeln, von datentechnischen Systemen iiber- 
nommen warden kann, die innerhalb des beschriebenen Verfahrens das gleiche Verhalten zeigen, und deren Funk- 
tion davon abhangig ist, daB die vom System vertretene Person diese Handlung durch eine WiUensauBerung dem 
System gegeniiber kundgetan hat. 
10 
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Zeichnung 3 - Zertifikatsverwaltung in einem Standard-Browser: 
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